> I am very frustrated by their opinion Right, but having different opinions on the language's design is not the same as Free Pascal having to catch up with De

> I am very frustrated by their opinion Right, but having different opinions on the language's design is not the same as Free Pascal having to catch up with Delphi. > And I use the trunk version (3.3.1). It is much less stable than the official releases. Well, yeah, it makes sense that an in-development version would be less stable than a stable release. This is why stable releases exist, otherwise their releases would just be nightly builds - and in fact the FPC developers even recommend avoid using development versions. (though i also use the SVN version in one of my projects and didn't have any issues) > The problem with longjmp exception handling is that it is slow[...]Any function that has automatic memory handling, has to do Ok, so those two are different things. A function being "slow" is something you have profiled in your application and ended up being "slow". What you describe is something that could cause your application be slow, but not something that is slow by itself. As i wrote previously, i've profiled my code on Linux - in fact i use Linux almost exclusively for profiling my Free Pascal code because prof shows me very detailed results with mixed assembly and source code that i cannot find a way to get under Windows (every tool i've tried assumes i use PDB files...) - and exception code has never been part of my profiles. I've profiled things from string parsers, to physics code, to rendering code, etc. But even beyond that if that is the case then... you can just solve it. If you think that using automated memory handling slows down your program's execution, then do not use it - automatic (or even manual) memory handling being a potential bottleneck isn't something surprising. Knowing the environment (which includes the way your compiler produces code) and adjusting your code to be performant for it is part of optimizing your program. Though in practice chances are fpc_ansistr_assign is going to be a bigger bottleneck than the exception support calls. And indeed, doing a quick benchmark with your code under Linux with perf (in a VM, though that shouldn't make much of a difference in practice) shows exactly that despite this being a synthetic example that will never be an issue in real code. In fact just modifying the code to do something more than just an assignment, like counting the number of spaces in a string pushes the exception stuff even lower in the profiler and modifying the code to do something that you may actually find in real code, like tokenizing the string pushes the exception support calls to sub-0.8% levels alongside some noise stuff from the kernel. This is basically a red herring, it looks like it might be a problem but in practice you'll end up against a lot of other issues trying to optimize your code before that becomes a problem by itself. > They google Lazarus, see it says "IDE", and then there is no point in talking to them anymore Ok but again, this is a problem with the people you're talking with, it has nothing to do with Lazarus or Free Pascal. > Me, too. But that is really bad. I do not see as bad at all, otherwise i wouldn't do it. The reason i stick with whatever comes with the language is that it tends to be stable and the FPC developers (as well as the Lazarus developers) care about not breaking people's code and have a very good track record when it comes to preserving backwards compatibility. I have code from almost two decades ago that compiles fine under Free Pascal without changes. Even the big change that was introduced in Free Pascal 3.0 with the codepage-aware strings only had me change one line of code in my codebase where i was treating a string as a byte array - i just changed that to rawbytestring. Packages by random people on the other hand might break or become unavailable or whatever. I do not want to rely on that. > The RTL is coupled with the compiler, so you cannot really update it without updating FPC. Like the JSON parser does not work properly. They fix it (or I did it), and with a package manager you could update it. You can always download the fixed JSON parser sources from the trunk. > But with FPC, you need to update FPC. But you cannot, because there is no release, for years. So you need to update to trunk and compile FPC yourself. But then you get an unstable, untested version, which is going to break a lot of unrelated code. Yes, having to either wait or build your own is something you'll have with any project that doesn't release new versions just for the sake of releasing new versions. But on the other hand Free Pascal's (and Lazarus') approach of actually releasing when the software is ready to be released (and this after making several release candidate versions before) means that you have a much higher chance of the version you get to be stable. > Today I actually looked at another JSON parser. It is probably better than FPC's, but I am not going to use it, because it is too much trouble to install it. Ok, but you not wanting to use a library that supposedly works better for your case because you think is too much trouble to download it isn't really Free Pascal's problem. > I looked at its code, and one of the first classes they implement in the JSON parser unit is a string builder. [...other stuff about string building...] Free Pascal is made entirely by volunteers, there is the open source community you seem to want - make a bug report, submit your improved string builder and if it is deemed good it'll become part of FPC. A faster string builder which is a genuine improvement (assuming it doesn't break any existing code - remember that backwards compatibility is important) would be gladly accepted. If not, just put it somewhere others may be able to take it (we already established there is a package manager but you can just put it in your site or whatever). If you do not want to participate then ok, that is fine too.