Nim 0.20.0 (1.0 RC1) released
nim-lang.org
nim-lang.org
That's... awesome. I've written a handful of little tools and scripts in Python for different (often non-technical) clients to use, but I've never found an easy way to package them up as a "click this icon to run the program" type of thing. If that's a solved problem with Nim I'm pretty much already sold.
However, the result, even for small scripts, is not what I would qualify as "small" :)
I also like pex (https://github.com/pantsbuild/pex) which allows to bundle a whole venv as a python script. Less heavy than nuitka, doesn't make it stand alone though, but very handy for quick and dirty scripts I want to one shot on my servers.
That doesn't remove any merit to nim. Such a cool project.
How does Nuitka compare for generated executable sizes with PyInstaller? I've used the latter. For small Python scripts, CLI or wxPython, it created EXEs (Windows) in the range of 10 MB in size - with the all-code-in-one-file option.
I use nim everyday. 98% of my programming is in nim only. I highly recommend nim. During the day I work mostly on internal tools and dashboards, during the night I work on games. Nim compiles to JS and C. Its really good.
Objective-C -> Swift
Python -> Nim
Ruby -> Crystal
JavaScript -> Elm—or maybe TypeScript?
C/C++ -> Rust
JavaScript -> Typescript
C# -> F# (or even modern C#)
Also they aren't guaranteed to be around forever.
Platform languages stay around while the platform is still relevant.
So, Kotlin is Android's Swift. Outside Android I bet that in 5 years it will be as relevant as Scala and clojure are today.
TypeScript is a wonderful language from Anders, but tsconfig.json allows to change the semantics in multiple ways and it is relatively hard to track down what changed in every release.
F# is only partially supported across all .NET deployment scenarios and VS Tooling. It was even left out of the new WinUI roadmap announced at BUILD 2019, even though .NET Core does support it.
(Obviously also a huge generalization :))
Not so much in the language design inspired by sense, but I see a lot of Go being used in places that were previously Java.
K8s was originally written in Java.
Personally very happy to operate fewer Java services...
Java 12 -> Go aka Java 1.4
haskell -> haskell> It combines successful concepts from mature languages like Python, Ada and Modula.
Rust on the other hand hurts my brain like Haskell as it is so foreign.
issue for Windows support has been open for... 6 years
> I don't have hope about language not backed/ created by large companies.
This does not align very well with history. PHP started as Rasmus Lerdorf toy, That didn't prevent it to grow and support some of the biggest platforms on the web. Python was also a one-man band for a while before it gained traction.
The future in uncertain.
That's right. Not yet.
One difference between the Swift and Nim communities is that where Swift's is full of noobs answering each other's questions, Nim's is full of experts who are just as eager to help.
Nim also has pretty good, fairly complete docs and a decent book.
That's grossly incorrect about Nim. I'm a C/C++ noob and I've found a lot of C/C++/Nim/CS experts answering my questions and helping me out on Nim IRC/Gitter/Nim Forums.
Recent (as recent as few hours ago) proof: https://forum.nim-lang.org/t/4912
...is correct, but
C -> Rust
...is not IMHO. There needs to be a much smaller, simpler, "better C" language than Rust to replace C. Something like zig, or C2, even C99 almost feels like a new language.
PS: ...and I forgot the fairly obvious C -> Go :)
From the GoPL (The Go Programming Language book, by Donovan and Kernighan), page xii, part of the genealogy is:
CSP (Hoare, 1978) -> Squeak (Cardelli & Pike, 1985) -> Newsqueak (Pike, 1989) -> Alef (Winterbottom, 1992) -> Go (Griesemer, Pike and Thompson, 2009).
To me at least, Rust looks like an obvious attempt to fix C++'s problems for large scale software development, but at the cost of being a big and complex language, similar in scope to C++. "Modern C" is a much simpler and elegant language, even though there's some decades old cruft, overall it remained a lot cleaner than C++ because there hasn't been so much stuff added in the first place which would be a burden now.
Go is fundamentally incompatible in most contexts C would be your go-to. A moderately heavy runtime with both a scheduler and a GC unable to compile down to a ".so"? C++ and Rust can both do those things readily.
Languages aren't just syntax/semantics, they're ecosystems within ecosystems. They fill niches with particular their capabilities.
A more appropriate comparison is Go to Java. Distict approaches to "half batteries included" robust application and service development.
Not even. Golang lacks the expressiveness and vast standard library in Java (e.g. nothing even close to what java.util.concurrent has), not to mention the very diverse ecosystem, tunable high performance GCs, and management capabilities of the JVM.
I can see golang being useful in smaller tools that have some networking capability (and with GraalVM+AOT, Java fills in that niche as well). However, with anything slightly more complex (including REST APIs), and it falls way short. So it shouldn't be compared to Java.
Python/NodeJS/Java/Ruby/Go all have a solid presence in the "I need to spin up a REST/SOA/gRPC/glue service wherever" niche. They each have a range of performance, expression, resource optimality, and ecosystem tradeoffs; but they're all still heavyweights in this particular domain. They each have a presence in other "types" of programming but I think it's also fair to compare them within this one.
Go has a few things which make it especially nice in this field out of the box. Goroutines + channels + select help solve the same class of problems that made reactor patterns, work stealing fork-join pools, listenable/completable futures so popular in Java-land. Go's sockets give you epolling for free where we'd use Netty in Java land.
In fact, they each if those language ecosystems struggle with that class of problem in this field: Good kernel thread utilization in the presence of very mixed cpu + network I/O load. What's why they all have a handful of the same approaches: Ruby/Python/NodeJS all do the reverse proxy on top n processes of of libuv/gevent/whatever event loops (reactor pattern). Java and Go are actually similar in that they actually try to use threads well within a single process.
I say this as an obsessive Java fanboy. I'm jealous of a few Go things I can't have: Goroutines (green threads) and flatter struct+array memory allocations. I can't wait for Loom and Valhalla.
You said it yourself. Once Java gets those, there isn't really much reason left to use golang. And with probably better performance as well (I know the techempower benchmarks have their issues, but if you noticed, golang's standard lib is towards the bottom of the list).
https://dlang.org/ is the main site.
https://tour.dlang.org/ is the D tour site, similar to the one for Go and some other languages nowadays; you can run some D example programs right from the site, without installing the language on your machine.
On my blog, I have a handful (12-13) of exploratory D programming posts, that may also be of interest. They explore various basic but interesting features of D via some simple D command-line programs:
The programmer will still be required to adhere to C-like manual memory semantics, with the difference being the language runtime catches safety mistakes. And then of course in bottlenecks the safety checks can be omitted.
If I accomplish my goal, the difference between safety/performance trade-off of Rust and Zig will be that Rust's release mode is both safe and fast, whereas Zig code has the simplicity but the programmer has to choose between performance and safety per scope.
https://github.com/ziglang/zig/issues/2007
granted neither does C, but C has cURL, and Zig doesnt (and wont) have cURL binding:
The issue you linked is saying tht zig standard library will not introduce a dependency on libcurl.
but surely you know the difference between FFI and binding?
They are not the same thing, and Zig doesnt (and wont, according to you) have cURL binding.
Objective-C -> Nim (can compile to ObjC, calls methods directly without overhead)
Python -> Nim (Nim is a super fast python that prevents typos)
Ruby -> Nim (Nim is better in every-way)
JavaScript -> Nim (compiles to plain JS (if you need talk to legacy JS libs like most people) or WASM (if you just want speed))
C/C++ -> Nim (Can compile to C++, calls methods directly without overhead)
I remember seeing lots of controversy over this feature a previous time Nim was posted here. Hopefully, its removal will stop people from dismissing the language outright (which would be a shame given all the things Nim has going for it).
(That being said, if people still want to embrace Wadler's Law [0], there's the hot-button topic of case/underscore insensitivity to talk about. [1])
[0] https://wiki.haskell.org/Wadler%27s_Law [1] https://github.com/nim-lang/Nim/wiki/Unofficial-FAQ#why-is-i...
[0] https://nim-lang.org/0.11.0/manual.html#syntax-strong-spaces
Obviously, the yikes is gone now. It was always an experimental feature, so IMO the fear of it was overblown, but it is a pretty scary idea for a feature.
re [0]: whether FUBAR and f_u_b_a_r mean the same thing or not is a matter of semantics, not syntax (it's in the name: "meaning").
re [1]: i use zsh where setopt errexit and setopt e_rR_EX_it mean the same thing, and it's really annoying. all it does is complicate search in man pages and code, i'd say this feature has negative value. e_rR_EX_it is extreme, but consider that zshoptions(1) documents ERR_EXIT while bash(1) lists errexit. i never know which to search for, and i end up mixing various spellings in zsh code. now shell options are a tiny slice of my shell scripts, but doing this for all identifiers? ugh!
i think the arguments in [1] are weak, unsubstantiated, and admissions of negative value.
It sounds to me like this is a problem with your search tool, if it would search in a style insensitive manner then this wouldn't be a problem, you'd find both.
https://nim-lang.org/docs/nimgrep.html
Excerpt:
Nimgrep is a command line tool for search&replace tasks. It can search for regex or peg patterns and can search whole directories at once. User confirmation for every single replace operation can be requested. Nimgrep has particularly good support for Nim's eccentric style insensitivity. Apart from that it is a generic text manipulation tool.
[0] If a language is not whitespace-sensitive I prefer curly brackets as block markers.
The plan AFAIK is to ship it with v1 but it would not be default and you would need to do `--newruntime` for using these features. As they stabilize over time and things get ported to this new runtime, it would be made the default.
I’ve been bitten by Python in this area a few times and I was looking for a statically typed alternative for a while. Nim seems to fit the bill.
The obvious choice would be Go, but the learning curve for my mostly Python-based shop seems higher and Nim looks cooler :)
Does the linked line imply that a slow client will block the rest of the clients from receiving new messages?
As a sloth I can become a horse to run fast.
I like Python, but let's not take an obvious weakness and try to present it as a strength. In the modern programming language landscape where you can get expressive and fast, Python is still slow.
I don’t get how anybody is claiming that Nim is at all comparable to Python. A nice syntax is like.... 1/10th the battle when you’re writing big projects.
I think the biggest problem in programming we have right now is people using libraries upon libraries not knowing how they work and drowning in complexity.
Huge ecosystems are almost like bureaucracies that eat productivity in their wake. They fool you into thinking they add value when instead they take it away.
Anyways for a lot of things Nim is pretty good actually and I would recommend people to atleast try it.
I'm pretty happy with Python though. It seems like Nim's benefits couldn't be that big. I consider Python "great", so the best Nim could be is "great-er", as a core language I mean. I've been rooting for Nim, but haven't actually tried it. And my use case is pretty small, I admit.
Nim provides a lot of features like compile-time execution, macros, c/c++/js/obj-c interop, upcoming newruntime, dependency free executable, better performance and lower memory overhead in general (obviously people can write bad code), etc.
So if any of these features matter to you, you should give it a try.
Unfortunately that can be somewhat of a chicken and egg problem for new languages.