Yeah, although one can argue they are badly designed if they do so from the performance/energy perspective.
1,123 karma · joined February 12, 2020
What do you on macOS that isn't available on Windows? Really curious.
The actual issue is this new Microsoft full of half-done projects and trying to reduce engineering costs. They even try to make others write the documentation for their products... MSDN is gone and now docs are a mess.
Ballmer was a mess, but at least he got the devs-first bit right. Nowadays it is devs-last, cloud-first.
The thing is that he originally served it from its domain so people use both interchangeably.
It is still a ton of time, about an order of magnitude more than optimal if the real/sys time split is to be believed.
In fact, in comparison, Go is pretty unstable compared to those two once you take into account the total time they have existed.
It is definitely not unique to Go.
In many countries, it is not even out of warranty!
Yes, some people change phones every year, but that does not mean the device itself is old just because you change it.
I know the Rust contributors are doing their best, and that this blog post is not writing a marketing ploy, but in the end, the result is what matters.
My take on this is that I am fine with compile times as long as some effort is being done to keep it near optimal.
But I really do not want the Rust team to feel pressure to improve the compile times so much that they will end up killing other features or designing the language differently just for that (like Go, for instance). Or even making the compiler so complex that adding new features is harder for them.
I really like Rust as a language that is more complex to write and to compile but in return gives you robustness and performance. Compilation times be damned. I am not writing Rust to compile fast!
Studying everything new is, of course, a much more ambitious goal.
Why would a C++ programmer learn Go? They should learn Rust since it is pretty much a cleaned up, modernized C++.
auto f = [&](...) { ... };
The last year of my PhD I ended up being pretty much alone because my advisor had changed research topics a year before and therefore was not interested nor up to date, so any of her inputs were not very useful.
A couple friends of mine also struggled with their advisor because he actively avoided communication for some reason. I guess he had a personal or health issue.
So even on good faith, advisors can end up making students life quite stressful for one reason or another
1. There is no law on the horizon that will require any accessibility for general purpose commercial apps.
2. Further, one can add accessibility features on Godot or other engines if needed. No technical limitation whatsoever.
3. If such laws came to be in a decade or two, engines and frameworks of all kinds will most likely support those features on their own.
4. The only case you can make against Godot is that someone has a company which hires people; and finds a blind person that is as productive as a non-blind to the point they are the best candidate for the job; and the company is in a country with such laws; and someone is an asshole that does not want to hire such person even if they are the best; and the position requires to use Godot tools; and the tools are non-accessible to begin with; and that someone does not want to spend the money to make them accesible; and the rejected candidate sues you and wins the case.
No business will even think about such an scenario. In an ideal world, they would. In the real world, they don't. And I am siding with the blind person in such a case and hoping such a company is busted in that case. But the case is extremely rare.
We are talking about web apps, not web sites.
> the screen reader output
The screen reader is not supported or useless on most web apps.
Again, we are talking apps and their GUI (web and native), not sites or documents.
> With something like godot, you might have to rewrite the entire GUI
Again a "might". I don't see any reason why you need any "rewrite".
> laws
Those are not for general purpose commercial apps as I wrote, only for public or specialized apps.
> You don't know anyone who's faced issues yet.
So then it is fear mongering, aka FUD.
> Provide information in accessible formats and technologies
Information, not GUI on apps.
Public information, at that.
It is simply impossible to require at the moment accessibility for web apps or native apps.
It does not even make sense for a huge amount of software. For example, an image editor or the vast majority of games cannot be accessible for a blind person with current technology.
Accessibility is critical on information and documents, not on common apps. That is why things like websites using fancy web frameworks just to display text is bad because they tend to break it. Nobody is discussing that, you are conflating apps with documents.
- Almost no one does accessibility properly in web apps. Even native apps get it wrong more often than not.
- Using Electron does not give you accessibility in any way.
- What laws? I use everyday general purpose commercial applications, both webapps and native apps, with glaring accessibility flaws and I do not see anybody caring to sue.
- I don't know of any business doing general purpose commercial applications that has faced any issues with that.
All major platforms offer advanced text rendering support.
How do you think Windows or macOS render their UI?
> what they do is paste a few characters on screen, handling a more common subset of Unicode.
Some games do that, in particular old ones or indies. Most games do actual text rendering properly.
> you can't open 100K lines of formatted code
You definitely can, but not naively. VS Code doesn't render all the text at once either and neither does any serious text editor.
Some engines do have accessibility support. Most games don't do accessibility because it costs money. Same as web apps, by the way. It is not a technical limitation.
> What about IME?
What about it? It works just fine in any proper engine. There are a lot of non-Latin-charset speakers in the world...
If it were true, then they wouldn't have the $110k a month in funding they have now.
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.