> What is it about writing views the React way that appeals to you more?
JSX is JS thus it's powerful. I prefer to use JS to "sprinkel the magic", rather than using yet another (awkward) template language. Using JS for everything is keeping my mental consistent. I enjoy getting full editor support for the entire app (typing (via TS), warnings, auto-suggestions, etc...). Overall it feels more consistent, more composable and more functional (as in Functional Programming) to me.
I hope the next big programming language will be one that is split into two language-variants: the "low-level-variant" and the "high-level-variant".
The high-level-variant is a dynamic language with optional typing, which is good for scripting, fast prototyping, fast time-to-market, etc.
The low-level-variant is similar to the high-level-variant (same syntax, same features mostly, same documentation), but it has no garbage collector, typing is mandatory and it runs fast like C/C++/Rust. Compiled packages that are written in the low-level-variant can be used from the high-level-variant with minimal effort or without additional effort at all. The tooling to achieve this comes with the language.
Yes, and I think Julia is a perfect starting point for an extremely productive general purpose language.
The one major wart with Julia is reliance on GC, I'm interested to hear what workarounds exist. If no common usage patterns rely on the GC, it should be possible to write "recycling" code that doesn't incur GC pauses and hence, unpredictable latency.
I really enjoy using Julia, it's a great balance of concision, expressiveness, and performance.
There is a common demand from people for extracting just a very concrete computation from a julia codebase and compiling it to a standalone library (or even just using it within an existing julia program, but guaranteeing certain allocation or real time behavior). For example, julia includes a pure julia implementation of libm, but we also maintain the openlibm C library, since we link it into some of our C dependencies that need good quality math functions. It would be nice just to compile the julia version and have it be a drop in replacement for the libm that can be linked. Of course for that you don't want the runtime, or GC or code generator. The challenge here is coming up with the right interfaces and abstractions to make this a feasible and useful thing, without splitting the community into those that care about it and those that don't. We've started some work in this direction, but it isn't really usable yet.
Is some concept of language support for traits/ interfaces and/or static typing part of this effort?
Also, would there be different levels of leanness for the static compile? I can see some people wanting binaries that use a minimal runtime or GC, but no heavy JIT etc so that a larger set of programs can be distributed but at some tradeoff.
Yes, for sure my suggestion was an incomplete answer, but still you would want the lower language be GC-aware/GC-compatible so I am not sure what the advantages of having two languages would be compared to having a GC language that can have non-GC modules/functions.
We also have an example of something more similar to what you are asking with Javascript+wasm (or better Typescript+wasm). I think they are both a fertile ground for future growth.
It's still a thing for the (loud) few who couldn't manage to move to 3 after 10 years. The rest just went on. The ecosystem is on 3 [0] and it has been for years now.
> The insane packaging situation. Packaging a Python app is a nightmare.
The packaging story in Python is in the middle of a big transformation from legacy tools to modern npm/yarn/cargo-like tools. pipenv [1] and poetry [2] are the most popular contenders. It will take a while until the community settles on this, but both tools work already.
Python 3.5 introduced type annotations. It is now possible to write statically typed code in Python via mypy [3], which from my experience works similar well as TypeScript works for JavaScript.
If I would have to port a code base from 2 to 3 today, I think the first thing I would do is add type annotations to to the code base via typing/mypy and go from there. A fully typed Python 2 code base shouldn't be too difficult to port with the help of mypy and proper editor support.
Which isn't a contratiction to the statement, that for the programmer the C interop is simple and elegant. Which I think mostly it is. The slowness comes from what goes on behind the szenes. Mostly the different way of handling stacks between Go and C creates quite some effort when calling into C and returning. Those languages, which use "C compatible" stack and register layouts get much faster C calling. That doesn't mean, they can call C as easily.
So calling C from Go for small functions isn't a performance gain. You should write those in Go. The calling of C is great for linking against larger libraries, which cannot be ported to Go. And for that it works nicely and is fast enough.
I find I use Go quite often to build relatively compact tools and services that need to use some features of a fully-featured and popular C library to perform some complex function that would be expensive and time-consuming to implement.
A recent example of this is using `libusb` and `libgphoto2` to enumerate DSLR cameras attached over USB and capture images from them in response to some other events, with a small web UI on top. It's maybe a few dozen lines of Go to call some enumeration and capture functions, and then I get a nice byte slice with all the data I want. There is minimal friction, the interaction is clear, and any performance cost is worth paying because of the simplicity of the interaction.
It's entirely true, and a well-known caveat, that the C FFI is slow. This makes it inappropriate for some use-cases, but entirely suitable for others.
> And for that it works nicely and is fast enough.
It may be fast enough for you, but it certainly isn't for many other people. golang will for example never grow a large mathy/scientific ecosystem, because of it.
