Neither Java nor Python are incredible languages as far as baseline features and semantics are concerned, but they continue to thrive because their ecosystems are fantastic and they both have really rich standard libraries to start from. Contrarily, quite a few languages I love from a language design perspective fail to gain as much traction for lack of well-developed ecosystems.
But in reality the language has severe impact on how the ecosystem can and will develop.
For instance, when looking at statically typed languages, it makes a huge difference if they offer a solution to the expression problem. That allows two author's to write two completely separate libraries (e.g. a library for an http server and a library for json-(de)serialization) which don't know anything about each other and then allows a third author to write another completely separate library that connects the other two libraries together, so that the http library can use the other library for json.
The end user then just has to important all three libraries and has compile time guarantees that it works.
If the language does not support that, then people will find workarounds. But it is still heavily impacting the ecosystem.
This so much.
One, often omitted, property is also simplicity of the language. If the language is straightforward, then there's a much larger audience who can be potential contributors.
Being opinionated in code style is also if value, as it's easy to contribute to others' libraries.
It's one of the reasons I think why Go did quite well as far as quick library ecosystem creation goes. It's fairly simple, at least as far as the basics go, and diving into/contributing to third party libraries is very easy, due to opinionated tools like gofmt and the overall language simplicity.
Whenever I need something in a library that's not supported yet, I'm able to achieve it in less than a few hours, by quickly diving in and making the changes, even in an unknown codebase. The magic is that this works for the vast majority of libraries.
A language needs to be good enough for developers to enjoy using it. Java was a breath of fresh air compared to 90s C/C++ code, so people were very motivated to build with it. Likewise, Python had a reputation for “Looking like pseudo code” which made it attractive to devs who needed a language that would let them build out ideas quickly.
That's too far. A language simply needs to not be actively bad.
Perl, unfortunately, was actively bad because everybody had their own subset of Perl that they knew and none of them overlapped.
When I was interveiwing for VLSI positions back in the mid 1990's, everybody would ask if you knew Perl. I would start whiteboarding and invariably would write something in Perl that the interviewer wouldn't know--which would effectively derail the interview. This is actively bad.
Python, by constrast, never had that problem. I used to carry to interviews printouts of a reasonably simple program in both Perl and Python (verilog VCD parser) so I could discuss them with the interviewer. The interviewer would always like the Python program better even if they didn't know Python.
(although, to be fair, it seems that Python has now grown that subsetting problem recently--how times change ...)
"Modern JS" has adopted many of the best features from TypeScript, but back when it launched it added so much cleaner syntax and abstractions over JS.
Others that have followed a similar route to success are Scala and Elixir for the JVM and Erlang VM.
With Nim, yeah there are way less libraries, but the ones it does have some how feel better. Also when there isn't you just write your own code specific to your missing use case. Which is not that not much code and fits better.
I think one of the biggest issues we currently suffer in the programming field is the use of libraries upon libraries, layers upon layers, without understanding.
this is like my biggest problem with rust, why i still lean towards python for getting things done and started learning go
I thought that Java used to be the main language CS courses in college were taught in and Python is the new standard teaching language.
That means lots of cheap new labor pumping out of colleges everywhere with Java and Python skill. Businesses will take advantage of that.
Python is for scripting software for quick playground.
The worst happen when you use the wrong tool for the job.
Android developers beg to differ.
> Python is for scripting software for quick playground.
Youtube begs to differ, along with hundreds more larger sites.
The problem was that, it wasn't [possibly still isn't] available in default Fedora repo while other less popular languages were available. No idea why. Might be due to low adaptation.
If the language is good, it won’t be very hard to install it without a package manager.
Fedora’s release cycle is on a six-month schedule so if it packages compilers for your languages, they shouldn’t be that outdated.
- Provide an easy way to install the Nim compiler and tools.
- Manage multiple Nim installations and allow them to be selected on-demand.
The first one I already get with the package manager I use for everything else. The second one I don't really care about as a normal user: I just need the one version at a time. As much as possible, I would rather stick with one way of managing tools rather than having sub-managers that I interact with infrequently and have to remember each time. (The same applies for me to other ecosystems, like Python.)
I'm sure it's useful for people who are working on nim itself, but speaking personally, choosenim actually has negative utility.
For Windows, I used to debug Rust using Visual Studio (not Code) without problems, because Windows binaries built for the windows-msvc target generate regular .pdb files that VS can work with regardless of the source language.
Both VS and gdb have a problem where the representation of Rust values when printed / watched is funky, especially with enums, because the Rust type gets translated into C terms. But it's not unworkable.
What baggage?
> Publishing your app as native AOT produces an app that is self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps start up very quickly and use less memory. Users of the application can run it on a machine that doesn't have the .NET runtime installed.
https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
Nim is the ultimate glue language, use libraries from anything: python, c, js, objc.
The inability of HN posts to stay on topic is pretty annoying.
Speaking of side projects, I recently built my own side project builder at just-kidding.org ;)
Don't know if they've made much headway lately, but for awhile even the main installer was getting flagged, as well as tools like choosenim.
Yes, I can hold lots of state in my head; and yes, I can make do without a debugger, if I have to.
But I don't want to. Especially since I've been so spoiled with PyCharm and Clion's way of doing it. My debugging time is limited and valuable, and a debugger that quickens my inspection of a program is nowadays so essential to my workflow that I'd rather hold back from committing to Nim at all until its debugger tooling (at least to the level of that in Jetbrains' IDEs) is available.
