Text input and manipulation is so incredibly ugly and hard, that basically nobody cares it enough to to it really well.
Unicode to start is complicated. Then you have things like bidirectional text.
Line breaking is complicated.
There are no accepted practices for a lot of use cases.
Hyperlinks. Embedded content like images.
Copying/inserting html and other formats.
Styling content.
Rendering 100 000 lines of styled content without screwing up user input.
Line-heights. Tabs. Font definitions that are ambiguous an inconsistent (a lot of font tables today still don't provide enough space for accents on capital letters, think Swedish - so you have broken looking text or have to 'fake it'). Screwed up Kerning tables.
No established standard for real pixelation and rendering - zoom in and you'll see font's can be rendered a variety of ways.
Emojis, fat finger cursor navigation on mobile devcies, input managers.
It's hard to describe how messy it gets because none of it is academic, it's not some scary-hard algorithm - it's just an incredibly ugly pile of cross-cutting code with a zillion little bits and pieces of corner cases.
And a big one for gaming engines: they don't render text 'natively'. You basically have to create textures. Every big of text, it's own texture. How big is the texture for 100 000 lines of code? Big.
This is actually one are where Qt falls flat. In the 'new and improved' Qt, they do everything in the GPU, if you try to load 100 000 lines of something the app will use up 1G of memory and puke. So then you have to magically code your way around it.
All for what? Why would you want to render text in a gaming engine in the first place ...
Then you discover that 'apps' and 'games' are really different things, and they use different tech for good reason. It only gets ugly when they really have cross paths.
Nobody is saying Godot should implement their own text engine. There are several available ones they can use, or just pick whatever the platform offers.
> Why would you want to render text in a gaming engine in the first place ...
Just about every game needs text, including Unicode text. Every proper engine handles it.
"Just about every game needs text, including Unicode text. Every proper engine handles it"
No, what they do is paste a few characters on screen, handling a more common subset of Unicode. They don't come close to handling most of the things I described above.
Not even Qt handles text well - Qt allows you to do some fun 3D things with text, but not you can't open 100K lines of formatted code like VSCode.
Webkit is just as bad - MS had to invent 'Monaco' a huge layer on top to be able to manage text properly and it's kind of a hack.
"All major platforms offer advanced text rendering support."
No, they don't realy.
I think you're missing a few pieces in your understanding of what the platform does in these contexts
The platform does not support text rendering for Qt and such platforms. They are rendered 'from scratch'.
Some platforms offer some built in components, but even they are quite limited.
No platform offers the ability, out of the box, to do for example, a 'coded editor' with properly highlighted syntax. Not even close.
"Most games do actual text rendering properly."
They are 'rendering text properly' for the extremely limited subset of text that they put on the screen.
Have you ever used even a basic 'text editor' in a game? No? Because they don't even do that.
" you can't open 100K lines of formatted code"
"You definitely can, but not naively."
'Natively' means nothing on the context of 'browser'. If you mean to say 'the browser doesn't do it out of the box' - then ok, yes, we agree. And why not, because it's extremely hard?
There are 0 comprehensive text APIs that are built upon gaming or even 3D engines today. Most of the barely handle basic text formatting. They put a few lines of text on the screen in a limited number of languages, and that's it.
There are very, very few platforms that offer comprehensive text rendering, including Qt, GTK, and native platform components - they're basic.
Providing comprehensive text API is not only something that has to be layered on top of those things - they also have to 'hack' those platforms to work around inherent bugs and limitations.
it's too late for the engine to "take care of it" when the problem presents itself - because there are existing tooling and frameworks that already fixes this problem (such as native widgets, or electron).
so godot will only see usage as a GUI framework for the use cases that won't see emoji or non-english IME.
> This is more efficient then using something like a game engine which has no concept about damaged regions and so on.
A game engine can avoid redraws trivially if no relevant input/event has occurred.
Further, AFAIK some graphic APIs do support dirty rectangles too, but to be honest, for desktop/laptop GUI apps I doubt it matters compared to anything else going on in the system.
And GUIs runs perfectly fine on integrated GPUs, further reducing the cost.
You can also do all your work in a raw text editor, yet you prefer VS Code. Same distinction for an actual IDE.
The Rust and C++ extensions are very far from what an IDE offers. They only handle basic debugging and code completion/browsing. With a few more extensions you can a bit better, but again, you are doing the job that an IDE is supposed to solve for you.
This keeps being repeated and repeated and it is just a myth.
Even without a package manager adding dependencies manually is quite easy for the vast majority of popular libraries. With a manager it is the same as cargo.
I assume you are talking about old, broken, unsupported, closed source, binary only libraries, but then it is not a meaningful comparison.
The question is the opposite: you have to prove to managers the benefit overcomes the risk of using a new language. Rust is still not nearly stable nor popular enough for many fields.
Go is a very different language with different goals and constraints, so the question does not really fit.
> Rust and Go are much simpler to learn
Go is a simple language, yes. Rust is a different beast with the same intrinsic complexity as C++.
> can do everything that C++
Not exactly true (for the moment). Rust is lacking on const generics, HKTs and other details.
> sane, simple and clean build systems/package managers
That is not a big argument for the kind of projects is used for.
And it is not true either, since nowadays there are several competing, modern package managers for C++ too (build2, Meson, Conan, modern CMake...).
> not to mention async/await concurrency
The async IO model has been available in many languages for many years, including C++. In the recent years several languages (including Rust and C++) are bringing syntax sugar to let the compiler create the state machines. But it is not the only way of doing async.
> The question is the opposite: you have to prove to managers the benefit overcomes the risk of using a new language. Rust is still not nearly stable nor popular enough for many fields.
I'm not sure what you're saying. Rust 1.0 code compiles just fine in the most recent rust compiler. It's been stable since that 1.0 point and promises to continue being stable. C++ doesn't have a a stable ABI either.
Tl;dr: C++ is now and will remain the near-exclusive choice for essentially all of the highest-paid, most demanding work in medtech, fintech, CAE, HPC, telecom, and aerospace, for decades to come. Rust code will never be able to call into the very powerful libraries these applications depend on, because they are based on language features Rust will never have. No language other than C++ and Rust targets these applications.
Very noisy Rust advocates here are inaudible elsewhere; many more people start using C++ in every week than the total who touch Rust in that week. That will not change soon.
Rust is a much better language than C, Go, Java, C#, Visual Basic, Delphi, COBOL, Nim, and Dart, and much faster than Python, Ruby, and Perl. Advocates would better focus recruiting there than tilting at C++.
Which license change? Last year? Blender technical and financial situation has changed very much since then.
Last year was the transition period to the new UI, new renderer and everything else. 2.80 was not polished at all.
Since then they got access to way more funds from major FAANGs (NVIDIA, AMD, Microsoft, Intel...) and announced and release the first LTS which are the ones intended to be used by commercial studios for long-term projects.
Now they need the time to use that money to hire and speed up things. Future looks very, very bright for Blender.
The Cinema 4D licensing changed to subscription which caused many people to look for alternatives.
I'm not arguing against Blender being an alternative eventually, it has great features. It's just not there yet as a complete replacement. For me at least.
That sounds like a development nightmare like the one of the IE6 era, and even worse for supporting customers.
Basically you are saying code performance is nondeterministic across your user base and across time too?
I am glad WebGL is a thing for pages that need some 3D widgets where performance is not a big deal. But for general software or games? I will keep my native software.
Instead of randomly picking from the 4 sides, pick one from the set of legal moves.