> The only area that saw significant retreat in macos is gaming.
Mac gaming is probably getting better thanks to wine, crossover, GPTK and Whisky [1]. I am not a gamer but I have seen others playing serious Windows games like FF7 remake (not sure if that counts) on mac.
The problem is, significant portion of "real games" used to run on macOS, and all PC games used to run on BootCamp. Now native mac games are all but extinct and cross-platform toolkits seem to be very hit and miss depending on the games (for now).
Sure, nothing beats bootcamp but that is not strictly macos. Apple's GPTK released last year seems to have greatly advanced gaming compatibility. Probably lots of games still don't work but it looks promising and is getting better. Hope Apple can continue to put resources into that.
I do hope that they would steer some of their resources from Apple Arcade into cross platform porting toolkits.
I think the fundamental problem still remains that games unlike softwares are media and cannot be substituted with equivalents. By pushing their proprietary tech and neglecting native macOS ecosystem over the years, Apple has willingly pushed themselves in to the same corner as with console makers where they cannot compete with the value proposition of PC because of the overwhelming majority of exclusive titles that only run on PC. It's either all or nothing in terms of game coverage, because that's what ultimately allows consumers to "buy one device for (mostly) everything" for a hobby that takes significant upfront investment unlike netflix and hulu for example.
> all serious numerical languages have that. it's more natural
And almost all serious general-purpose languages use 0-based. It is more natural at least to me. You see, this is exactly why 1-based index of Julia is disliked by many.
If your goal is to promote Julia, your comments here are having exactly the opposite effect on me.
Style aside, you can't simultaneously complain that Julia doesn't get the resources of a general-audience language and then talk down to "general-purposes folks". Julia could be the bees knees for math-y stuff. And if so, good for it. But Python's success is because its flexibility makes it pretty good for a wide range of things, even if it'll never be great for any one of them.
i bet u dont do numerical computing so julia ain't for u anyway.
i love python. in fact, in my daily run on cloud run it's one of the key component since it has a decent gcp client library for writing query code to bigquery.
but then i glue it up with bash and run some other analysis in julia.
i think you can have python, julia, bash, r, whatever. heck, i even dabled in go and react.
just saying julia is aimed at numerical first.
and i think 0-based indexing was merely a historical accident anyway due to lack of memory in early computers so use every last bit including the 0 even though it's not suitable for indexing but is suited for calculating mem offsets.
whatever, use whatever u like, not trying to promote julia to you or anyone else. just having a good argument on friday afternoon
It is not just syntax. While python has Java-like OOP from a far, Julia has a distinct language design. It doesn't have a concept of "class" in the traditional sense. It instead has multiple dispatch, which is very flexible but sometimes too flexible to control. I found Julia harder to write for an averaged programmer. Furthermore, the time-to-first-plot problem had pissed off many early adopters (I know a few and they won't come back) and apparently remains a problem for some [1].
Julia is a great niche language for what it is good at. It will survive but won't gain much popularity.
There are even more issues with Julia than you mention there. But the point is there are _many issues_ with _every_ programming language:
Python is slow, its package management story is a dumpster fire, its object model is bizarre and confusing, its typechecking mechanism sucks. Also, its documentation is terrible (docstrings and documentation of functions) and the built-in REPL is basically useless.
Rust has slow compile times, too much macro magic leading to unreadable code, the 90% of what the borrow checker rejects is perfectly fine code, its trait coherence rules are too restrictive, async sucks, and it's totally unsuitable for quick experimentation.
These are all real limitations, but users of these languages learn to live with them. Rustacenans learn to start a build, then so something else while it builds. That is, on its face, totally unacceptable to a Pythonista. Pythonistas learn to always ship performance sensitive applications with _another language_ doing all the hard work: Totally unacceptable for a Rustacean.
If someone tries out Python, spends five minutes getting package management to work and fails, they have not seriously thought about Python as a language. I feel people do just that with Julia: Try it out, then reject it on the first rough edge.
Fair enough: There are many people for whom lack of static type checking or Julia's latency is a showstopper, making the language unsuitable. But I'm still firmly convinced that for scientists/engineers at least, Julia, on balance, offers a better language than Python. I hope you're wrong that it won't gain much popularity.
i work in a bank leading some numerical work and I've been training my staff on Julia so we can write monte-simulation code that is fast. heck, the team builds their model in C++ and we soundly beat them with Julia on the code that generates the same results.
when we looked at it, it was because c++ is hard af to learn and the developer dont use it to its full potential. they just use some quantlib which where you look under the hood has many unoptimized parts.
with julia, the code is so simple and clean we even put in some GPU code in one place using CUDA and complete blows the C++ out of the water.
I did achieve some good performace with numba once thought with the avx so pythoni snot all bad but numba is only a small subset of python but with julia i can do crazily fast stuff that looks like python and is readable.
It seems that Julia has been used for numerical stuffs often. Its redmonk ranking is above some great languages like nim and erlang. This is already an achievement for a community-backed open-source language. By "much popularity", I meant "as popular as Java or Python". I had a high hope for Julia.
It's not going to be solved. Stop saying this. It's a great step forward and a real user experience improvement, but it doesn't solve it.
Packages need to precompile, and they don't. They need to fix invalidations, and they don't. They need to fix inference issues in their packages and they don't. "Using" time remains quite high.
Technically we've only released the first release candidate for 1.9. There's still a few bugs in it, and we'll probably have at least 1 more release candidate before 1.9.0 is released.
Also want to add that getting a formal certificate for learning disabilities is expensive. From what I heard, an ADHD test costs a couple of thousand USD, which could mean a lot to low income families.
Fully agree. The python community just wouldn't admit they lack someone as good as Mike Pall or the V8 team. The python performance in the computer language benchmark games is so embarrassing especially on the benchmarks not requiring external libraries [1].
For a library, if the user input is wrong, throw an error or an assertion failure. It shouldn't be causing an uninformative segmentation fault which your library does. The fix is a trivial. Why so defensive?
Probably many have written a vector header like this. It baffles me why this one reaches the front page of HN given that the implementation is not that great. A few problems (some have been mentioned by others as well).
1. not using "do {} while (0)". This may lead to compile errors.
2. using uint32_t for capacity. On 64-bit machine, this doesn't save memory.
3. DYN_ARR_RESIZE() may have a quadratic time complexity if some is calling DYN_ARR_RESIZE(a, 10); DYN_ARR_RESIZE(a, 11); DYN_ARR_RESIZE(a, 12) etc in a loop. kv_resize() in kvec.h wouldn't have this problem.
It’s better that the code isn’t perfect. Reading the code review comments in this thread has been really valuable for me personally. Like, I’m not sure I would’ve learned about the do-while trick had so many people not pointed it out.
> But if your code was truly performance-critical, you wouldn't be piecing it together with shell pipelines that cause a bunch of unnecessary forks, you'd write it in something like C instead.
You are underestimating the power of unix tools. A chain of unix tools can match or exceed the performance of C programs written by average programmers. That is a true beauty of unix and partly why it is still relevant today. The author has little idea about performance and doesn't understand how unix works; otherwise he wouldn't make arrogant claims like:
> With jc, we can make the linux world a better place until the OS and GNU tools join us in the 21’st century!
Mac gaming is probably getting better thanks to wine, crossover, GPTK and Whisky [1]. I am not a gamer but I have seen others playing serious Windows games like FF7 remake (not sure if that counts) on mac.
[1] https://github.com/Whisky-App/Whisky