"I started out coding in the mid-90s and refocused my career on Bitcoin and crypto in 2016 after leaving a very large software company in Seattle."
You're embarrassed to have worked at Microsoft but not on crypto pyramid schemes?
Choosing Nim out of a crowded market for systems programming languages
261–270 of 271 posts
Re: Choosing Nim out of a crowded market for systems programming languages
#262Earlier quoted context omitted.
I dislike when a discussion turns into "I have to teach you the basics now". I'm just not willing to engage in that most of the time with strangers on the internet because they usually don't want to be taught, they want to be right. Explaining that you can express complex dynamic lifetimes in Rust using 'unsafe' and module-level safety is a waste of my time because it's empirically true.
But you are engaging with strangers on the internet. You're just not doing it in a way that's particularly edifying. Indirectly insulting me and others doesn't help your case on that front. Let me turn it back on you. By refusing to educate people on what you think they got wrong, you come across looking like just what you're worried about: someone who just wants to be right. If your goal is to defend Rust, I would s…
I made an accurate statement. Anyone can take it or leave it.
If you want help learning the language I'd suggest the Discord or subreddit, people will be happy to assist.
Re: Choosing Nim out of a crowded market for systems programming languages
#263Earlier quoted context omitted.
> looking very much into Nim to see if I can replace Rust because of the high cognitive load to keep all of the Rust stuff in my head, as I don't really need safety. Personally I find that Rust has less cognitive load, because so much of what you'd generally worry about in other languages is covered by language features in Rust: static typing, algebraic data types, etc
I'm sometimes a bit confused when people say that Rust has less cognitive load. I assume that's compared to something like C or C++, right? I've used Rust and (imperative-style) Scala a lot, and I have to say, Scala is way easier since it doesn't have to deal with the borrow checker, but it still has an amazing type system. Nim is statically typed and has algebraic data types, so I imagine it's also as easy as Scala,…
Imagine if someone said "I've used Python and Scala and Python is way easier since I don't have to deal with a type system". That's where people are coming from.
The borrow checker isn't a hindrance, it's an aid. Rust gives me syntax to describe lifetimes and a tool to check that syntax.
Re: Choosing Nim out of a crowded market for systems programming languages
#264Earlier quoted context omitted.
I honestly don't think your options should be between Nim and Rust. Nim has a very small community, and almost nobody is hiring for Nim experience. Going through Nim's forum, I think most developers tend to work on Nim projects alone. If marketability is your priority, learn the popular languages like java, c, c++, golang etc. Even people hiring Rust developers usually have some leeway to hire someone who can learn R…
I think you are jumping to conclusions about my choices. Why do you explain to me how to decide when you don't know my objectives and constraints? My main language is Python, to that I'd like to add a compiled, native code, fast-ish, statically typed language with good Python interop. That takes away JVM and .net languages and leaves, roughly, C++, Rust, Nim, maybe Go. I take Go off because I don't like it. I also ca…
> Why do you explain to me how to decide when you don't know my objectives and constraints?
You asked a question. You didn't provide any context. I took the initiative to answer the question based on the mere statement of "Nim vs Rust".
My intial feedback still holds true. Does your job require you to learn anything specific or do you want to learn anything just because?
> I take Go off because I don't like it. I also can't stand modern C++.
You are giving your personal opinion and without context. Why do you not like Go.... never mind. It is the weekend, try Nim and Rust both, see what you like.
Re: Choosing Nim out of a crowded market for systems programming languages
#265It will be interesting to look again once Nim reaches 2.0. And Crystal still requires lots of work on compiler and Windows Support. I just wish it had more resources. Along with Zig. All three of them need more time to mature.
Re: Choosing Nim out of a crowded market for systems programming languages
#266Earlier quoted context omitted.
Why not? Making identation part of the syntax allows more for less?
You cannot cut and paste freely when indentation matter
Yes ok, but this is not very limiting and doesn't make this approach a ridiculous and failed one to start with, as the OP originally suggested and those languages which do it disprove already?
Re: Choosing Nim out of a crowded market for systems programming languages
#267Earlier quoted context omitted.
The issue with D is it still feels unpolished. Every time I try it - which is maybe once a year or so - the experience still feels weird and edge casey. The idea that a GC is somehow a hindrance to language adoption doesn't make any sense to me at all. Doesn't stop people loving Go. But go has slick tooling.
I had one experience with Go. It was slow because the GC kept kicking in. So we won’t use Go again in favor of time-tested C++. GC is a major reason we are using C++ over Go. In my mind it’s a half-speed language. I’m also very put off by Rob Pike’s “Look, we replaced C++!” attitude when he somehow doesn’t seem to grok zero-cost abstractions. C++ has plenty of issues, but it doesn’t have GC and it goes further, provi…
I haven't seen Go's hit larger than 25% in our production.
Usually that means we have to keep average CPU load below 70%. (Since GC cames once in several minutes, it is usually not seen in per-minute averages)
That is ok for us, since Go significantly boosts development compared to stricter language.
It is "marketplace" thing, so we have enough money to spend on additional 50% servers compared to "extremely efficient No-GC" solutions.
It all depends.
Re: Choosing Nim out of a crowded market for systems programming languages
#268Earlier quoted context omitted.
It doesn't? https://nim-lang.org/docs/re.html and https://nim-lang.org/docs/net.html are part of nim's standard library. Are they missing something you expect?
They are dependent on pcre and openssl respectively unlike Golang which is native.
Well, sure Golang, but to be fair they are not native pure Python in Python's stdlib either...
This is more broadly relevant since part of the appeal of Nim is its easy C/C++ interoperability (by generating to these and so only requiring some declaration).
Re: Choosing Nim out of a crowded market for systems programming languages
#269Earlier quoted context omitted.
How would functional programming help with Rust? I am fluent in both, and having map and reduce in the Iterator trait does not make Rust anything like a functional language.
The things that make rust “functional” are features like a type system that supports sum and product types and functions as typed values that can be passed around. It really is a functional language (in the original ML sense of the word) but with another orthogonal type system bolted on (borrow checker). It’s missing some features like higher kinded types but it’s functional nonetheless. I’m interested to hear what y…
Jeez downvoters - just look at the definition of “functional language”
https://en.m.wikipedia.org/wiki/Functional_programming
And then tell me Rust is _not_ those things.
Re: Choosing Nim out of a crowded market for systems programming languages
#270> [..] I decided that I need a safe, fast, and statically typed language that can be compiled and targeted to both mobile and desktop environments, as well as being made available to scripting languages via FFI. And you eliminated Rust because.. it’s too complicated? It meets these requirements to the letter! Since this is a greenfield effort, would it really be too expensive to invest some time to learn it? Anyways,…
Hi, article author, here. Down in one of your other replies, you state:
> The context for that question is important: OP had a set of requirements and Rust seemed to meet them.
The context as I presented it is perhaps unfairly narrow, and I've glossed over some of the non-technical requirements that constrain my choices. Time-to-market and funding levels are hyper critical - these are hard limits that have less riding on me-as-IC being the sole determinant of a positive outcome, and more on being able to hire the first team members should I meet my funding goals in 2023. Here in the EU, hiring rust devs is ultra-competitive, expensive, and open positions tend to sit unfilled for longer periods of time. There is a mercenary like attitude among experienced crypto developers that makes it difficult to recruit for projects. A developer who is good with rust and knows crypto well doesn't need you for a job - they're probably already looking for funding or considering a co-founder position with a biz person that's already snared a wealthy benefactor for advisory and seed funding. This makes building a founding team (vs a team of co-founders) very difficult in the space.
On the flip side, I can teach a good JVM / golang / python / NodeJS developer how to iterate in nim a lot faster than bringing them up to speed as a proficient rust developer.
My top considerations were among "productive" compiled languages: go, crystal, swift, even investigating mruby. These languages have considerably less cognitive surface-area in banging out pedestrian and proprietary IP code in a 7:1 ratio (not scientific, obvs). First, you need to quickly produce MVP and v1.0 products. Secondly, the follow-on to that is being able to support fast iteration to launch and prune features. This latter aspect is much more important than the zero-to-MVP phase, since the clock isn't really running until you're actively marketing a project and it's gaining (or losing) users. Rust is just not a good choice for the entire code base. It is, however, a great-to-good choice for low-level dependencies. Given it's flexibility, I think Nim can be both. We'll see.
There are two documents that haunt my thoughts over the course of decades being in tech startups. One of them is Paul Graham's "Beating the Averages". The other is Akin's Laws of Spacecraft Design.
One of Paul's reasons for using Lisp at Viaweb was, paraphrasing here for brevity, that choosing the defaults of your competitors is going to yield an average result, which will put you out of business. In my industry vertical, I do think that Golang is more that default than is rust. The evidence seems to point toward Go based teams being better at burning through VC (tongue firmly in cheek ;-) ), and that Rust is superior at embedding working technology whose code-paths touch every customer, every day.
My sincere hope is that Nim hits the sweet spot in the middle while eeking out some of the competitive advantages that Graham talks about. As the idiom goes, you takes your money, and you makes your bets.
http://www.paulgraham.com/avg.html
As for Akin, the full list has some doozies but the one that really sticks out to me in the context of startups is this:
40. (McBryan's Law) You can't make it better until you make it work.
https://spacecraft.ssl.umd.edu/akins_laws.html
cheers