That said: Nim does look nice.
Take javascript, for instance. If you're used to a C style based language with some functional patterns, jumping into a codebase and understand it is quite easy. But around the language itself you also need to know stuff like npm, webpack or similar, how the browser works, http concepts etc etc.
Or python, need to deal with pip, virtualenvs, perhaps poetry, need to understand the limitations to concurrency because of the GIL and how it affects deployments, perhaps django or some other framework, etc.
What's more interesting and what's more difficult to find shortcuts for is understanding the spirit of the language, knowing its weaknesses, bottlenecks and inner workings. The threading model, what's done at compile time and what's done at run time, etc etc. There are so many things you need to learn before you can judge any given language relative to others that you know.
* dependency management and releases
* deploying and running in prod
* footguns that affect performance or security
* libraries for helping development
* language-specific features
etc
Ecosystem > language awesomeness
Provided that one ecosystem is huge (e.g. Python) and the other one small.
With that said, learning to write production code in a small language allows for certain better developments in mindset (e.g. Stack Overflow? Forget about it) and better in the quirks of the language, which you will see (to a lesser extent) in other languages.
By your logic no community-driven project would ever be successful.
When it comes to safety- or mission-critical software, crashing due to a dangling pointer, a stack overflow or a failed allocation are equally catastrophic, and not crashing but producing a wrong answer due to an algorithmic error is also equally catastrophic. In fact, producing the correct answer late can also be just as catastrophic when the system is real-time -- we don't care if the operation takes 1ms or 99ms, but if the deadline for emitting a control command is at 100ms, emitting it 100.001ms late is just as catastrophic as a crash (while completing the calculation in 20ms or 95ms is equally good). Never crashing for any reason, never producing a wrong result, and never producing a correct result late are all equally critical.
How are such systems written? They normally require very simple code and very simple algorithms -- to make analysis by tools, and even more importantly, by humans as easy as possible. Any compiler magic or implicitness in the code may be problematic (possibly including reference-counting if a bound on deallocation time cannot be guaranteed). We don't want to make code as fast as possible, but as non-surprising and as predictable as possible.
Similarly the worst bugs can be crashes (random, non-deterministic, release-mode only, timing sensitive heisenbugs), or they can be undetected algorithmic errors.
It entirely depends on the specifics. But either way, Rust's tradeoffs are easily worth it in terms of eliminating bugs unless you really don't care.
Unfortunately the author only provides the code for nim.
So it is subjective based on a simple practical project (1000 locs). Unfortunately it leaves out all the other "cool kids" like crystal, zig, v, dart, d and so forth...
https://github.com/mode80?tab=repositories&q=Yahtzee&type=&l...
> But the big dealbreaker with Julia is it only complies on the fly. That means you can't just hand a compiled executable to someone. You must give them instructions to install Julia and all your dependencies first. That's no good for anything you want to ship like a desktop app or a game. You also don't want Julia on your server recompiling with every web request.
That's an issue with Python as well, but the Julia team is working on that.
https://github.com/JuliaLang/PackageCompiler.jl
And getting things precompiled: https://sciml.ai/news/2022/09/21/compile_time/
About a year ago I was very off-put by someone on Reddit who sort of scolded me for wanting to use Julia as a general-purpose scripting language at the CLI. The Redditor said this wasn't as idiomatic usage of Julia. Idk how representative this is of the community at large.
In particular, functional languages (Haskell, Ocaml etc) and array-based languages (J, q/kdb or one of the many free clones out there).
Seeing what is capable in those paradigms is very eye opening.
http://emmanueltouzery.github.io/blog/posts/2016-10-13-teach...
Although a former co-worker said in a break-chat that it's best to learn something from both sides top down and bottom up. I'm just not sure how that would work.
Large ecosystems don't have such issue, because what you get is communities, not monopoly. (Look at some toolings like Sidekiq enterprise).
Out of Python, R and Julia, just learn ONE for 1y and become the best at it. That way, you can build anything in that language and then use that to build something mind-blowing.
So python:
a = [0,1,2,3,4,5]
a[0:5] => [0,1,2,3,4] - half closed interval
a[0:-1] => [0,1,2,3,4] - negative indexing
a[:5] => [0,1,2,3,4] - skipping start index
a[3:] => [3,4,5] - skipping end index
var a = [0,1,2,3,4,5]
a[0..5] = [0,1,2,3,4,5] - closed interval
a[0..^1] = [0,1,2,3,4,5] - closed interval with negative indexing
a[..4] = [0,1,2,3,4] - skipping start index
a[..<5] - Error - doesn't work
a[3..] - Error - doesn't work
a[0..<5] = [0,1,2,3,4] - half closed interval
a[0..< ^1] = [0,1,2,3,4] - half closed interval with negative indexing
(Important - the white space is required, it will crash otherwise!)
but then notice later
func icon(forFile fullPath: String) -> NSImage
func icon(forFiles fullPaths: [String]) -> NSImage?
func icon(for contentType: UTType) -> NSImage
func with same name, can have different named parameter, and return type.
func iconForFile
func iconForFiles
func iconForContentType
Will be the alternative in every other language(paramtype overload is available in c*/java/kotlin to extent, but it is less explicit), Swift sounds neat isn't it?
You can see more examples, in particularly class overloads it looks cleaner and convenient to communicate, verbosity is not an issue, code is optimised for reading.
https://developer.apple.com/documentation/appkit/nsapplicati...
The actual issue with Swift, is tooling and there's SOOOOOO many hidden wanted/unwanted "feature"
Swift: 840 lines
Nim: 768 lines
C#: 872 lines
Julia: 761 lines
Rust: 861 lines
Python: 550 lines
I am curious what a good APL-er [better than me] could do without trying to codegolf it, and how it performs.
I feel the other way. LINQ is great for building pipelines. List comprehensions are kinda like English, but it gets ugly when you use the flattening feature, or when you want something more than just map and filter.
Looking at their C# code, they’re going at it in a fairly low-level way, with a lot of aliases for numeric types and a lot of casting between them. For example:
private static f32 distinct_arrangements_for(DieVal[] dieval_vec) {
var key_counts = dieval_vec.GroupBy(x=>x).Select(g=>(g.Key, (u8)g.Count()));
uint divisor=1;
uint non_zero_dievals=0;
foreach (var (key, count) in key_counts){
if (key != 0){
divisor *= factorial(count);
non_zero_dievals += count;
}
}
return factorial(non_zero_dievals) / divisor;
}
private static float DistinctArrangementsFor(DieVal[] dievals) {
var dievalCounts = dievals
.GroupBy(x => x)
.Where(group => group.Key != 0)
.Select(group => group.Count())
.ToArray();
var divisor = dievalCounts
.Select(factorial)
.Aggregate(1, (a, b) => a * b);
var nonZeroDievals = dievalCounts.Sum();
return factorial(nonZeroDievals) / divisor;
}
There are a few more weird things, like not using switch statements/switch expressions, or this function:
// calculate relevant counts for gamestate: required lookups and saves
public int counts() {
var ticks = 0;
var false_true = new bool[] {true, false};
var just_false = new bool[] {false};
foreach (var subset_len in Range(1,open_slots.Count)){
var combos = open_slots.Combinations(subset_len);
foreach (var slots_vec in combos ) {
var slots = new Slots(slots_vec.ToArray());
var joker_rules = slots.has(YAHTZEE); // yahtzees aren't wild whenever yahtzee slot is still available
var totals = Slots.useful_upper_totals(slots);
foreach (var _ in totals) {
foreach (var __ in joker_rules? false_true : just_false ){
// var slot_lookups = (subset_len * subset_len==1? 1 : 2) * 252; // * subset_len as u64;
// var dice_lookups = 848484; // // previoiusly verified by counting up by 1s in the actual loop. however chunking forward is faster
// lookups += (dice_lookups + slot_lookups); this tends to overflow so use "normalized" ticks below
ticks++; // this just counts the cost of one pass through the bar.tick call in the dice-choose section of build_cache() loop
} } } }
return (int)ticks;
}
If this code was rewritten in more idiomatic C#, it could be the basis of a good comparison between languages’ performance and syntax. But I’m not sure if it’s a good example at this point.
counts() was a throw-away for initializing the progress bar, so I was a little lazy there
Float you mention was needed for the looping calc at the call site.
Appreciate the feedback
I don't understand this complaint? "Named parameters" i.e. keyword arguments in functions work great in Julia!
julia> foo(;x = 1, y = 2, z = 3) = x + y + z
foo (generic function with 1 method)
julia> foo(; z = 4, y = 0)
5
julia> foo(x = 1, y = 2, z = 3) = x + y + z
foo (generic function with 3 methods)
julia> foo(3)
8
julia> foo(0, 0, 0)
0
This is almost entirely mitigated by most people using `eachindex` or `axes` or other functions that make the array related code index agnostic. The only reason I say almost entirely is because there's probably some really old code that doesn't work the right way and would silently fail or do the wrong thing if you changed the indexing convention. That said, calling this a "deal-breaker for scientific computing" seems extreme.
> I also find Julia's errors to be fairly obtuse. And I see a lot of them because dynamic typing means the tools can't catch most errors before run-time.
I 100% agree. Julia errors are my biggest gripe with the language at the moment.
> But the big dealbreaker with Julia is it only complies on the fly. That means you can't just hand a compiled executable to someone. You must give them instructions to install Julia and all your dependencies first. That's no good for anything you want to ship like a desktop app or a game. You also don't want Julia on your server recompiling with every web request.
There are packages like PackageCompiler that work pretty well. And I'm positive in the near future (3 years?) we'll have a version of Julia where PackageCompiler will produce small binaries. That said, the convenience of writing in Julia and shipping a precompiled app is pretty awesome, and I personally don't mind it taking more space on disk.
> Like all compiled languages, the development cycle involves a lot of recompiling as you go. For small programs it doesn't matter, but this creeps up as the program grows -- or when you add a heavy dependency, like a plotting library. Julia suffers from this compiled-language drawback, but without the normal advantage of getting a compiled executable you could distribute.
This used to be one of my biggest gripes, but things have gotten a lot better with every version of Julia.
----
My first order approximation when picking a language is this:
1) if I think it'll be easy to write in Python, I should write it in Julia. 2) If I want to ship a precompiled binary that exposes a command line interface, I'll think about using Julia first, and if the size of the binaries are an issue, I might pick Rust.
wrt to Nim, I'm waiting to see how the ORC story shakes out + better documentation about ORC to appear on the scene and for more packages to adopt it. I think Nim currently has too small a community. I've found packages that are commonplace in Rust or Julia are just not even available in Nim. Sometimes a package is 5 years old and hasn't been updated. Yes, it is easy to write interfaces but that requires a lot of work. If it is a project where I'm writing code just by myself, Nim might be a good choice but if I'm working with someone else, having them learn Nim is much harder. The error messages in Nim also need to get better in my opinion.
> You don't have to decide between snake_case or camelCase. You can define your variable either way and both references will work. Ditto for most cases of capitalization. I thought this might be problematic, but in practice it's brilliant. I think that sentiment applies to many of Nim's unexpected design choices.
I personally don't like this at all. Every time I search a nim codebase, I have to use `nimgrep` instead of using `ripgrep`. I have SO many aliases built on top of things like `ripgrep` and `fzf` and none of them are certain to work in `Nim`. It's frustrating that the community is so divided on this, because even though I can see there are benefits to this approach, the benefits pale in comparison to getting user adoption and buy in to use the language.
One of my senior developers on my team agreed to learn Nim in their spare time as a favor to me, to evaluate it for a project at work, and as soon as they came across this "feature" they were so turned off, they wrote the language off as being too weird.
There's a LOT of average programmers out there, and a lot more analysts and data scientists that just want to get shit done, and from personal experience I think it's extremely hard to get adoption for Nim in the scientific community. If 7 out of 10 people have used Python, 4 out of 10 people may have heard of Julia and heard that it's new and modern, but 0 people have even heard of Nim. I've gotten SO many quizzical looks over the years, it is not even funny.
May I ask what's your involvement in the Nim community, I don't recognize your username? Also sorry to say but if your colleagues look you like that maybe they don't respect you?