14 ms·

I have done an unhealthy amount of comparing around the languages in this space. I'm curious what others think about the tradeoffs between choosing Nim/D/Go/Cry

I have done an unhealthy amount of comparing around the languages in this space. I'm curious what others think about the tradeoffs between choosing Nim/D/Go/Crystal/C#/Java/Kotlin? Previously I would have not included Rust in that grouping, but I've finally bitten the bullet and started learning it... and now I would, high level abstractions with low level control, etc etc. Essentially there's a class of programs that are performance sensitive, but also dev time sensitive. How do you choose between the set above? (The answer, if there is one, is probably Python, and then optimize the hotspots, but lets pretend we can indulge). - Nim: fast dev time; fast performance; not v1, C/C++ interop is second to none. Newruntime seems awesome - C#: medium dev time; med-fast performance; very OO, coreRT and readToRun are awesome - D: fast dev time?; fastish performance; I haven't written more than a few lines - Go: fast dev time; med-fast performance; interop is expensive, lack of high level abstractions - Crystal: ?; fast?; have not used - Java: medium dev time; med-fast performance; very OO, GraalVM is cool - Kotlin: fast dev time; med-fast performance; kotlin native may be cool some day - Rust: slow/medium dev time; fast; safe, awesome type system - C: slow dev time; fastest?; unsafe / current tooling and docs are like performing an archeological dig. - C++: medium/slow dev time; fast; unsafe / full of intricacies All of the above are obviously opinions gained over time with sources forgotten and I've only written a few hundred lines in each language. PL ADD is real. At the moment, Rust is scratching all the itches though, and I'm excited to see if my mental model of programming adapts to the language and dev speed is not an issue. Obviously I like collecting hammers and am less good at finding nails. Very cool to see D getting picked up for some serious use. D and Nim are fantastic and hopefully thrive in the coming years. I would love to see a write up of what led them to choose D.

apta 7y ago
There are other factors to include as well. Monitoring and management are quite important, and this is where environments like the JVM and .NET do a very good job. Ecosystem maturity, availability of mature and quality libraries, availability of good quality documentation, community size and support. I find these guidelines to be a good starting point when deciding what stack to go with, as opposed to what the latest hyped languages are. We've already seen people go with hype, only to realize and backtrack their decision to use a more mature and well established language and ecosystem.
- totalperspectiv 7y ago
  These are excellent points. I haven't spent a lot of time in JVM land. But the tooling and resources in .Net land are fantastic and can't be ignored.
jandrewrogers 7y ago
On the performance dimension, I am pretty sure C++ effectively passed C a while ago given good compilers. At the very least, it requires significantly more code and effort to make C as fast as modern C++.
- totalperspectiv 7y ago
  Good point, I had always just taken for granted that C would be faster, and it's not! (Obvious disclaimers about benchmarks inserted here https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/cpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...).
  - igouy 7y ago
    > and it's not! Well those numbers seem to show some C programs are faster than the C++ programs they are compared to; and other programs are not.
  - __d 7y ago
    I'll point out that those benchmarks show C++ faster for four, C faster for five, and both the same for one scenario. Modern C++ enables some very concise expression, at the cost of significant language complexity, and enormous compile-time cost. C requires more work from the programmer, but is vastly quicker to compile.
- flukus 7y ago
  > I am pretty sure C++ effectively passed C a while ago given good compilers Citation? Every benchmark I've ever seen still has C coming out on top: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/c.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... . The gap has narrowed and c++ can be better in specific situations but it has not "effectively passed" C, not to mention uses less memory. Here is another one: https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sle...
  - 7y ago
earenndil 7y ago
C, D, C++, rust, and nim should all have comparable performance; they all go through gcc|llvm, and all have the same optimizations. Rust and c++ may be slower in debug mode than their other-language counterparts, but the cost of abstractions goes away when optimizations are turned on (in exchange for drastically increased compile times). Java is not significantly more OO than C++; global-scope variables and functions in c++ are analogous to static ones in java. D's interop story is similar to nim. I don't know rust, but I believe it is said to be more expressive than c++. Honestly, I think all the judgements of dev time are a little bit misleading; iirc there were some studies showing that productivity is not significantly different across languages. Worth noting, though, is that D and Go compile really quickly.
- totalperspectiv 7y ago
  Your comment on dev time is something I intuitively agree with. And there are the future costs of dev time to add new features later / debug code etc. It's a poor measure at the end of they day. As to C/D/C++/Rust/Nim, what I think is interesting to see, is which ones lead you to the performant path naturally, vs having to really dig into the bowels of the language or go against the grain of the language, so to speak. I have not written enough of any of them to say which do this. I would hazard that Rust does the best job, due to its explicitness / very nature.
  - earenndil 7y ago
    > I would hazard that Rust does the best job, due to its explicitness / very nature I might say the same about c, except even more so. As for 'the performant path', something to watch for there is jai, probably coming out later this year. It has clever things there, like dynamically switching between SOA and AOS, or doing small dynamic allocations on the stack.
    - totalperspectiv 7y ago
      I haven't looked at Jai. I'll have to check it out. I have looked at Zig, which seems to inhabit a similar space. They both seem a little too early days for me at the moment (I at least want a chance at using it $work), but I like the general idea of better C.
maxxxxx 7y ago
Is Rust slower dev time compared to C++? That doesn't sound good. Also C# dev time is much faster than C++. C++ done right is hard.
- totalperspectiv 7y ago
  I adjusted them to both be 'slow/medium'. It's all rather subjective and handwavy to be sure.
  - maxxxxx 7y ago
    Maybe another interesting factor would be learning curve. I bet C++ and Rust have a pretty steep one compared to Go for example.
- pjmlp 7y ago
  Try to write GUI code in Rust and then in C++.
opportune 7y ago
I would say C# dev time is rather fast. I stood up a medium size project recently without ever having used C# in a serious project before and it was pretty fast to set up. I'd say the main thing hindering dev time would be if you have people you're working with who need things to be done the "enterprise" way (i.e. needlessly extensible and abstracted). But if you don't have those people, it can be much faster to write than Java due to the better tooling and standard libraries. Also less popular languages might be missing very nice features that make the quality of life of deploying/testing/etc. better, which is really important if you are just setting up a small-medium sized project where you yourself are responsible for the devops. I found C#/.NET (still not exactly sure where one ends and one begins...) very easy to work with in this regard, and I'm sure Java and Go are also probably pretty good here. But I expect C and Rust are not so good.
- giancarlostoro 7y ago
  C# is the language and syntax while .NET is the runtime and libraries (or Framework). Compared to Java, Java is the language, the JVM is the runtime, and the JDK are the libraries.
- nicoburns 7y ago
  You might be surprised how good Rust is ops-wise. Unit testing sipport comes out of the box, and it's hard to beat a static binary for deployment (compile times are a pain for CI though). Rwgarding C#, that language and core tooling is indeed pretty nice. But I was surprised to find the library ecosystem quite lacking in some places. Basic things like JSON (de)serialization seemed pretty clunky, and the long tail of libraries I expect coming from the JS/PHP ecosystems seemed to be pretty non-existent.
  - Const-me 7y ago
    > Basic things like JSON (de)serialization seemed pretty clunky The built-in one is.. strange. Newtonsoft.JSON is _the_ most downloaded third-party library for .NET: https://www.nuget.org/stats/packages https://www.nuget.org/stats/packages I like it, very flexible, in a good way.
zem 7y ago
if you're not confining yourself to c-like languages, i like ocaml a lot too for a combination of fast dev time and good performance. has some cross-platform issues and multicore support is still lacking. if you have some familiarity with rust you should already be used to a lot of the ideas present in ocaml. also, if you are already familiar with c#, there's f# which is essentially a port of ocaml to .net. won't improve the performance of c# but might improve the dev time a bit.
- totalperspectiv 7y ago
  I have gone down the ocaml rabbit hole before. Likely, it was too early in my programming career and I got wrecked by the combination of novel concepts, poor docs, disjointed toolchain, and lack of ecosystem. I have, in more recent times, played with F# which is very nice.
  - xvilka 7y ago
    A lot of these issues are now solved. OCaml universe now switched to Dune[1] as an uniform buildsystem, using ocamlformat[2] as an uniform formatting tool (succeeding over ocp-indent), Base[3] standard library aims to be the only one, a lot of legacy cruft was removed in recent compiler versions, along with improved error messages. Real World OCaml book[4] is now being modernized for the second edition. Recently even the design of documentation produced with odoc was improved and cleaned up a lot So it tries to catch up with more modern programming languages. [1] https://dune.build https://dune.build [2] https://github.com/ocaml-ppx/ocamlformat https://github.com/ocaml-ppx/ocamlformat [3] https://opensource.janestreet.com/base/ https://opensource.janestreet.com/base/ [4] https://dev.realworldocaml.org/ https://dev.realworldocaml.org/
jdc 7y ago
FWIW Java is is gradually working in some promising new productivity features (many of which fall under the Project Amber umbrella). https://news.ycombinator.com/item?id=20269840 https://news.ycombinator.com/item?id=20269840
Skunkleton 7y ago
C won't have slow dev time, assuming that experienced devs are writing the code. There are a ton of abstractions directly accessible from C, and lots of people know them really well. C might not be fastest though. Rust can make more optimizations than C for example. Fortran is often faster than C too.
- seanmcdirmid 7y ago
  C programmers have to spend more work writing and maintaining a line of code given its low level focus; if you substitute in experienced programmers you might as well do that for the other languages as well.
lenkite 7y ago
Java's productivity is high with good choice of libraries and an IDE that Intellij that offers fantastic refactoring, code generation and code-intention abilities. And Kotlin's productivity is even more higher since all the above apply along with convenience language features for succinct and functional-style coding. So I would rate Java as fast and Kotlin as very fast in the dev productivity scale. You can really push the pedal in these two if you are working in an IDE and you can change your design iteratively on the go thanks to excellent tooling.
baybal2 7y ago
D for me is a guarantee of continuity. Unlike languages kept on corporate "life support" there is not so much risk of it becoming abandonware or sponsors "pulling the plug" on it. I'm very sure that C will outlive Go, Rust, and probably us all. I'm not so sure about the current wave of "a better take on C++" type languages
- pjmlp 7y ago
  C will outlive those languages as long as we keep POSIX and UNIX clones alive, that is all.
electrograv 7y ago
If you’re looking for more “PL ADD” fuel, don’t forget to look into Zig! https://ziglang.org/ https://ziglang.org/ Of all the modern systems level programming languages I’ve seen, I like Zig the most. It combines a powerful, modern type system (generics, algebraic data types, statically checked null references) with an impressive simplicity (e.g. without the productivity-consuming and mentally burdensome “borrow checker” of Rust).
- bb1234 7y ago
  Question: For someone who does not know either Rust or Zig, would you say that Zig also has tools that help the programmer protect from data race conditions (I have read that Rust is helpful in this regard)?
- totalperspectiv 7y ago
  I have looked at Zig! It looks sweet, but a little to early days for me personally. For example, there's no documentation on how to open a read a line from a file. The best I can find is an example implementation of `cat` in the source repo. I will certainly be coming back to it at some point though.
- pcwalton 7y ago
  > without the productivity-consuming and mentally burdensome “borrow checker” of Rust The borrow checker also gives you memory safety, which Zig does not have at the moment. Solving use-after-free and related issues is a hard problem. I have yet to see a way to solve it that doesn't boil down to one of runtime garbage collection, not allowing heap allocation at all, not freeing memory at all, or a region system/borrow checking. It's fine to not like the borrow checker, but it's there for a reason.
  - pjmlp 7y ago
    Yeah, but currently it still is a roadblock when writing GUI code, to the point that Gtk-rs samples use macros to overcome the boilerplate to access widget data from callbacks.
- 7y ago
squarefoot 7y ago
"- Crystal: ?; fast?; have not used" Ruby is an extremely powerful language, with the only drawback of being truly slow. Crystal solves this problem with flying colors by offering almost full Ruby compatibility along with very efficient native code generation. Unfortunately it's still young and lacks user base as well as ports to other architectures.
- dymk 7y ago
  Lacking the Ruby ecosystem means it lacks like, 90% of the reason you’d choose a language.
- petre 7y ago
  Yup, quite fast. On par with Go. Compiling Crystal is also fast and the language is beautiful.
  - bb1234 7y ago
    According to the benchmarks at https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks, Crystal is about twice as fast as Go.
  - omaranto 7y ago
    In a discussion involving C, C++, Rust and Nim, "on par with Go" is probably not considered fast. Also, it would seem Crystal is closer to those languages I mentioned than to Go in speed.
- jashmatthews 7y ago
  >almost full Ruby compatibility Crystal is very different from Ruby. Hello world will copy paste but there are major differences after that.
pjmlp 7y ago
Adding to your list: - Swift: C# like productivity, compiles to native code, however mostly constrained to Apple platforms - Eiffel: RAD tooling, uses JIT for development, compiles to native code via C and C++ compilers for deployment, mostly constrained to enterprises that value correction above all and are willing to pay its prices - Delphi: One of the best RAD tooling still around, with compilation to native code, while allowing all the low level stuff from C and C++; Mostly safe, suffers from manual memory management. Borland mismanagement placed it as enterprise devtool. You can use Lazarus/FreePascal as alternative - Ada/SPARK. Compiles to native. Also enjoys fast compilations. For devs and companies that care about code quality. Besides GNAT all the remaining implementations have enterprise level prices
- jamesmp98 7y ago
  Ada has always been intriguing to me. Is it used much anywhere these days?
  - pjmlp 7y ago
    Avionics, trains, oil rigs, basically everything where human life's are at stake, deemed as High Integrity Computing. Only 4 languages apply, Java with Real Time extensions, C and C++ with certification processes like MISRA and AUTOSAR among others, and Ada/SPARK.
pb82 7y ago
Golang has good cross compilation built in. You can easily build Linux binaries on a Mac. Makes deployment and containers almost as painless as the interpreted/jited languages.
- pjmlp 7y ago
  Only works for pure Go code.
cshenton 7y ago
Julia is the fastest (in speed achievable in a short dev time) language I’ve ever used. Especially for any scientific computing workloads.
- petre 7y ago
  Probably not easily embedable on a vehicle though.
- totalperspectiv 7y ago
  I really want to love Julia. I've never gotten over the startup time, slow string functions, and package manager repl thing. Perhaps I was getting into it at a bad time, right around the time the new package manager was being announced. The whole thing felt very magic... too R like for comfort.
  - philzook 7y ago
    The start up times really bug me too. I think the solution might be sticking to a Jupyter/Juno session or keeping a repl open and reloading. https://github.com/timholy/Revise.jl https://github.com/timholy/Revise.jl It is incredible the degree with which small inconveniences can inhibit adoption.
- locoman88 7y ago
  Bullet-trains are very fast too, but they need rail tracks. C++/C/Nim/Rust/D are all terrain fast
jonathanstrange 7y ago
I have chosen Go for now, after having learned Nim and Rust. I also know Ada, FreePascal, Racket, CL and a bunch of other languages fairly well. Python was never an option, because it's too slow and (subjective opinion) a very ugly language. There were clear reasons why Go was the best choice for me: Pros: - large infrastructure, many third party libraries - good tooling - fast compilation speed - reasonably fast executables (fast enough) - (just) good enough GUI bindings - although it almost failed on that one - automatic garbage collection Cons: - lack of generics - a bit too much verbosity (if err!=nil) - million dollar mistake Subjective assessment of the other languages (for me, and my type of projects - remember, a programming language is only a tool for a certain purpose): - Nim is a great language, but unfortunately seems to be eternally unready for prime time. Lack of complete enough GUI bindings. - Rust is a convoluted language and has no garbage collection. It is marginally better than Ada at the cost of readability, has a number of minor misfeatures, and an unnecessarily steep learning curve. I predict it to have the same complexity or higher than C++ in ten years from now, with all the disadvantages and security issues this brings. Especially macros are a very, very bad idea. (They also count against Nim in my book.) - D is a very good language and on my list of things to learn. Reasons for deciding against it were primarily its nearness to C++ and the express intent of the developers to get rid of garbage collection in favour of some convoluted, needlessly complex borrow checking. (Unfortunately, D also has macros, but they are less obtrusive and less needed than in Rust.) - C: dev time too slow - C++: dev time too slow, too many pitfalls (even if you use just a subset, at some point you will have to deal with esoteric code and bugs that require 40+ of experience to understand); ugly language. - Kotlin: Java VM is out of question, the long-term technology support on some platforms is too uncertain. - Crystal: issues with multithreading (if I remember correctly), lack of a good enough GUI binding. - Java: out of question - I consider it legacy technology, I've used it in the past and found the frameworks to be horrible (too much OOP); ugly language; future VM support too uncertain on some platforms. - Julia: very nice language, fast; it lacked a good enough GUI binding last time I checked, but once it has one, it will be on my list of things to test. - Zig: interesting but too close to C, no garbage collection, only manual memory management. - FreePascal/Lazarus: probably the best GUI support but mostly manual memory management and felt kind of old; basically, I didn't choose it for fear of accumulating too much technological debt. - Ada: probably the static language I like the most, has everything I need, but is pretty much dead - not enough third party libraries, single vendor lock-in, only GTK as viable GUI option, fear of accumulating too much technological debt; it's a pity, because I think it's the best language among those mentioned so far. - Racket: my main language for the past 20 years, I have developed successfully GUI applications with it, large tooling, fast enough, BUT: application startup time too slow, rich text editors too sluggish, GUI slightly too limited, professional deployment can be complicated (by professional I mean with all correct metadata, icons, according to OS guidelines, code signing, sandboxing, etc.), dynamic typing bad. - CommonLisp: probably a good choice for high-tech long-term, large-scale web-based applications like booking systems or scheduling systems; libraries suffer from lack of documentation, executable sizes and memory consumption fairly large, bindings to C/C++ libraries notoriously incomplete or undocumented; dynamic typing bad. Okay, that's it. These are all purely subjective evaluations for the purpose of writing fun, fast, compact, mid-size cross-platform GUI end-user applications. I should mention that in a more professional setting I would probably bite into the sour apple and just go with C++/Qt. But that wouldn't imply having fun, which is one of my goals.
JoshuaScript 7y ago
You'll definitely want to check out ATS[0]. It's a functional, dependently-typed language with performance on par with C(its compilation target), and has a type system and theorem prover that guarantees memory-safe code. [0] http://www.ats-lang.org http://www.ats-lang.org
- philzook 7y ago
  I am personally very intrigued by ATS, I think it is striving for a truly unique and powerful point in the programming language space, but have extreme reservations about it being ready for general use. Do you consider it ready for adoption, or are bringing it up as a learning exercise?
  - JoshuaScript 7y ago
    > I am personally very intrigued by ATS As am I. I'd say this, along with Idris and Agda are showing how useful types can be. > Do you consider it ready for adoption People have written non-trivial software in it[0], but because it hasn't yet reached a 1.0 release, I wouldn't say it's quite ready for adoption. It seems to be more of an academic project for now. [0] https://github.com/xlq/aos https://github.com/xlq/aos
lmm 7y ago
> Essentially there's a class of programs that are performance sensitive, but also dev time sensitive. How do you choose between the set above? (The answer, if there is one, is probably Python, and then optimize the hotspots, but lets pretend we can indulge). Only if you don't believe other languages can be more productive than Python. IME an ML-like language with type inference and good development tools will be faster to work with than Python, at least as soon as you have to edit code (for a script short enough that you can write it out and expect to be correct first time Python might still win). I regard the ML featureset as table stakes for a language these days; while most languages (all serious languages?) have first-class functions, proper sum types are so useful that I don't want to use a language without them. That cuts the list of possibilities down quite a lot: in terms of having enough maturity/popularity for production use it probably comes down to OCaml (which becomes the default option by seniority), Haskell, F#, Scala, Rust, Swift, or Kotlin. D or Nim just don't offer anything compelling that's worth giving up sum types for, and while Swift or Kotlin can more or less equal OCaml they don't offer a compelling advantage. Any of OCaml/Haskell/F#/Scala/Rust is a defensible choice. Haskell and Scala offer higher-kinded types, which are immensely useful once you get used to them. F# and Scala offer decent IDEs/tooling in a way that the others mostly don't. Rust offers a limited form of linear typing, but as a special case built into the language rather than as functionality emerging from a general type system; you can achieve a similar level of resource safety with a rank-2 type trick (famously used in ST) in a language that supports those (i.e. Haskell or Scala). I use Scala for everything these days. Better-than-Python dev time, better-than-Rust type system, Nim/Java/C#/Go/D/Kotlin-like performance, and first-class Java interop (which I consider better than C/C++ interop, because using C/C++ interop makes your whole program memory-unsafe). Bonus of a compile-to-JS implementation that just works with the same code that you can run in your IDE.
- gdy 7y ago
  "higher-kinded types, which are immensely useful once you get used to them" Could you give an example of such immense usefulnes?
  - lmm 7y ago
    All of the problems that aspect-oriented programming tries to solve, but without any reflectioney magic. So for example I have a custom type to represent database operations that need to happen within a transaction; the type system ensures that there will be a transaction boundary around them eventually, but I can still compose together several different such functions and run a single transaction around them all. In theory you could do this with a "command object", but in a language without HKT you'd have to reimplement all the utility functions that make it practical to use those objects (e.g. traverse, which takes a list of must-happen-in-transaction commands and combines them into a single command that will evaluate to a list) and in practice people doing this kind of thing in Java/C#/Python/... give up and fall back to reflection/AOP/metaclasses/decorators, because it's too cumbersome to manage the transaction boundaries explicitly. But then you get things like http://thecodelesscode.com/case/211 http://thecodelesscode.com/case/211 happening. With HKT you can have reusable, generic functions that work on any kind of effect - all the examples on https://philipnilsson.github.io/Badness10k/escaping-hell-with-monads/ https://philipnilsson.github.io/Badness10k/escaping-hell-wit... and more. E.g. a tree structure library will offer a traversal method that can already handle doing an effectful operation at each level and composing together the effects correctly - even if it's an effect that didn't exist when that library was written. That makes it practical to manage these effects/cross-cutting concerns explicitly, which enables fearless refactoring (it's always clear whether you can e.g. reorder some statements without changing behaviour or not), so you need much less test coverage for the same level of confidence which in turn makes refactoring even easier, and you end up with a virtuous cycle where your code stays clear because it's always easy to refactor for clarity.
jsjsjsjsjsjs 7y ago
> - Nim: C/C++ interop is second to none. This is very wrong. There is perfect c interop - you can import c functions using {.importc.} pragma. C++ interop is best i have seen so far. You can use c++ template types! Here is the sample: https://github.com/3dicc/Urhonimo/blob/master/modules/container/hashmap.nim https://github.com/3dicc/Urhonimo/blob/master/modules/contai... Of course it is not perfect. For example if you would like to override c++ method you will have to write a bit of c++ code using {.emit.} pragma. I do not know a single language that could map c++ template types into it's own generic types like nim can.
- Leszek 7y ago
  "second to none" means "best" ("there is no one it is second to, thus it is first")
  - jsjsjsjsjsjs 7y ago
    TIL. Not native english-speaker. My bad.
    - totalperspectiv 7y ago
      You made my point better though! Nim interop is awesome.
- detaro 7y ago
  "second to none" means "the best".
- deleted 7y ago
  [deleted]
- mhh__ 7y ago
  D's C++ interop looks better at a glance. With a simple extern(C++) you can use templates, classes and vtable's are matched up to single inheritance. There is also some experimental work on catching C++ exceptions but I've never tried to use it.
0xDEEPFAC 7y ago
Ada is being actively used by Nvidia in some of their research: https://blogs.nvidia.com/blog/2019/02/05/adacore-secure-autonomous-driving/ https://blogs.nvidia.com/blog/2019/02/05/adacore-secure-auto...
- totalperspectiv 7y ago
  I have always wanted to look into Ada, but could never see being able to make a serious business case to use it for real things at the moment.
  - exhilaration 7y ago
    It's used widely in defense, much less in private industry. The exception is if you write Oracle PL/SQL - that resembles ADA.
bb1234 7y ago
Since you are asking about performance of some languages, you may find this helpful https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks
pif 7y ago
> but also dev time sensitive. What do you call dev time? Time till we have a prototype to play with and refine the idea? Time till we release a quick & dirty version and start counting the hours before the first bug report? Or time till we can ship and forget?
_448 7y ago
Oh! Where did my Pony (https://www.ponylang.io/ https://www.ponylang.io/) go? :)
kitd 7y ago
The biggest dev-time factors in my professional work time are: 1. A (de-facto) standard toolchain, incl pkg management 2. A rich ecosystem of 3rd-party packages. Which sadly rules out a number of languages that would otherwise be very interesting. Without those 2, I can spend hours fighting with implementing code that I know could be done in a few minutes with a more widely-used language.
EvenThisAcronym 7y ago
- D: lightning fast dev time; fast compile times; performance directly comparable to C and C++; metaprogramming capabilities second only to Lisp.

apta 7y ago

There are other factors to include as well. Monitoring and management are quite important, and this is where environments like the JVM and .NET do a very good job. Ecosystem maturity, availability of mature and quality libraries, availability of good quality documentation, community size and support. I find these guidelines to be a good starting point when deciding what stack to go with, as opposed to what the latest hyped languages are. We've already seen people go with hype, only to realize and backtrack their decision to use a more mature and well established language and ecosystem.

totalperspectiv 7y ago
These are excellent points. I haven't spent a lot of time in JVM land. But the tooling and resources in .Net land are fantastic and can't be ignored.

jandrewrogers 7y ago

On the performance dimension, I am pretty sure C++ effectively passed C a while ago given good compilers. At the very least, it requires significantly more code and effort to make C as fast as modern C++.

totalperspectiv 7y ago
Good point, I had always just taken for granted that C would be faster, and it's not! (Obvious disclaimers about benchmarks inserted here https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/cpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...).
- igouy 7y ago
  > and it's not! Well those numbers seem to show some C programs are faster than the C++ programs they are compared to; and other programs are not.
- __d 7y ago
  I'll point out that those benchmarks show C++ faster for four, C faster for five, and both the same for one scenario. Modern C++ enables some very concise expression, at the cost of significant language complexity, and enormous compile-time cost. C requires more work from the programmer, but is vastly quicker to compile.
flukus 7y ago
> I am pretty sure C++ effectively passed C a while ago given good compilers Citation? Every benchmark I've ever seen still has C coming out on top: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/c.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... . The gap has narrowed and c++ can be better in specific situations but it has not "effectively passed" C, not to mention uses less memory. Here is another one: https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sle...
- 7y ago

earenndil 7y ago

C, D, C++, rust, and nim should all have comparable performance; they all go through gcc|llvm, and all have the same optimizations. Rust and c++ may be slower in debug mode than their other-language counterparts, but the cost of abstractions goes away when optimizations are turned on (in exchange for drastically increased compile times). Java is not significantly more OO than C++; global-scope variables and functions in c++ are analogous to static ones in java. D's interop story is similar to nim. I don't know rust, but I believe it is said to be more expressive than c++. Honestly, I think all the judgements of dev time are a little bit misleading; iirc there were some studies showing that productivity is not significantly different across languages. Worth noting, though, is that D and Go compile really quickly.

totalperspectiv 7y ago
Your comment on dev time is something I intuitively agree with. And there are the future costs of dev time to add new features later / debug code etc. It's a poor measure at the end of they day. As to C/D/C++/Rust/Nim, what I think is interesting to see, is which ones lead you to the performant path naturally, vs having to really dig into the bowels of the language or go against the grain of the language, so to speak. I have not written enough of any of them to say which do this. I would hazard that Rust does the best job, due to its explicitness / very nature.
- earenndil 7y ago
  > I would hazard that Rust does the best job, due to its explicitness / very nature I might say the same about c, except even more so. As for 'the performant path', something to watch for there is jai, probably coming out later this year. It has clever things there, like dynamically switching between SOA and AOS, or doing small dynamic allocations on the stack.
  - totalperspectiv 7y ago
    I haven't looked at Jai. I'll have to check it out. I have looked at Zig, which seems to inhabit a similar space. They both seem a little too early days for me at the moment (I at least want a chance at using it $work), but I like the general idea of better C.

maxxxxx 7y ago

Is Rust slower dev time compared to C++? That doesn't sound good. Also C# dev time is much faster than C++. C++ done right is hard.

totalperspectiv 7y ago
I adjusted them to both be 'slow/medium'. It's all rather subjective and handwavy to be sure.
- maxxxxx 7y ago
  Maybe another interesting factor would be learning curve. I bet C++ and Rust have a pretty steep one compared to Go for example.
pjmlp 7y ago
Try to write GUI code in Rust and then in C++.

opportune 7y ago

I would say C# dev time is rather fast. I stood up a medium size project recently without ever having used C# in a serious project before and it was pretty fast to set up. I'd say the main thing hindering dev time would be if you have people you're working with who need things to be done the "enterprise" way (i.e. needlessly extensible and abstracted). But if you don't have those people, it can be much faster to write than Java due to the better tooling and standard libraries. Also less popular languages might be missing very nice features that make the quality of life of deploying/testing/etc. better, which is really important if you are just setting up a small-medium sized project where you yourself are responsible for the devops. I found C#/.NET (still not exactly sure where one ends and one begins...) very easy to work with in this regard, and I'm sure Java and Go are also probably pretty good here. But I expect C and Rust are not so good.

giancarlostoro 7y ago
C# is the language and syntax while .NET is the runtime and libraries (or Framework). Compared to Java, Java is the language, the JVM is the runtime, and the JDK are the libraries.
nicoburns 7y ago
You might be surprised how good Rust is ops-wise. Unit testing sipport comes out of the box, and it's hard to beat a static binary for deployment (compile times are a pain for CI though). Rwgarding C#, that language and core tooling is indeed pretty nice. But I was surprised to find the library ecosystem quite lacking in some places. Basic things like JSON (de)serialization seemed pretty clunky, and the long tail of libraries I expect coming from the JS/PHP ecosystems seemed to be pretty non-existent.
- Const-me 7y ago
  > Basic things like JSON (de)serialization seemed pretty clunky The built-in one is.. strange. Newtonsoft.JSON is _the_ most downloaded third-party library for .NET: https://www.nuget.org/stats/packages https://www.nuget.org/stats/packages I like it, very flexible, in a good way.

zem 7y ago

if you're not confining yourself to c-like languages, i like ocaml a lot too for a combination of fast dev time and good performance. has some cross-platform issues and multicore support is still lacking. if you have some familiarity with rust you should already be used to a lot of the ideas present in ocaml. also, if you are already familiar with c#, there's f# which is essentially a port of ocaml to .net. won't improve the performance of c# but might improve the dev time a bit.

totalperspectiv 7y ago
I have gone down the ocaml rabbit hole before. Likely, it was too early in my programming career and I got wrecked by the combination of novel concepts, poor docs, disjointed toolchain, and lack of ecosystem. I have, in more recent times, played with F# which is very nice.
- xvilka 7y ago
  A lot of these issues are now solved. OCaml universe now switched to Dune[1] as an uniform buildsystem, using ocamlformat[2] as an uniform formatting tool (succeeding over ocp-indent), Base[3] standard library aims to be the only one, a lot of legacy cruft was removed in recent compiler versions, along with improved error messages. Real World OCaml book[4] is now being modernized for the second edition. Recently even the design of documentation produced with odoc was improved and cleaned up a lot So it tries to catch up with more modern programming languages. [1] https://dune.build https://dune.build [2] https://github.com/ocaml-ppx/ocamlformat https://github.com/ocaml-ppx/ocamlformat [3] https://opensource.janestreet.com/base/ https://opensource.janestreet.com/base/ [4] https://dev.realworldocaml.org/ https://dev.realworldocaml.org/

jdc 7y ago

FWIW Java is is gradually working in some promising new productivity features (many of which fall under the Project Amber umbrella). https://news.ycombinator.com/item?id=20269840 https://news.ycombinator.com/item?id=20269840

Skunkleton 7y ago

C won't have slow dev time, assuming that experienced devs are writing the code. There are a ton of abstractions directly accessible from C, and lots of people know them really well. C might not be fastest though. Rust can make more optimizations than C for example. Fortran is often faster than C too.

seanmcdirmid 7y ago
C programmers have to spend more work writing and maintaining a line of code given its low level focus; if you substitute in experienced programmers you might as well do that for the other languages as well.

lenkite 7y ago

Java's productivity is high with good choice of libraries and an IDE that Intellij that offers fantastic refactoring, code generation and code-intention abilities. And Kotlin's productivity is even more higher since all the above apply along with convenience language features for succinct and functional-style coding. So I would rate Java as fast and Kotlin as very fast in the dev productivity scale. You can really push the pedal in these two if you are working in an IDE and you can change your design iteratively on the go thanks to excellent tooling.

baybal2 7y ago

D for me is a guarantee of continuity. Unlike languages kept on corporate "life support" there is not so much risk of it becoming abandonware or sponsors "pulling the plug" on it. I'm very sure that C will outlive Go, Rust, and probably us all. I'm not so sure about the current wave of "a better take on C++" type languages

pjmlp 7y ago
C will outlive those languages as long as we keep POSIX and UNIX clones alive, that is all.

electrograv 7y ago

If you’re looking for more “PL ADD” fuel, don’t forget to look into Zig! https://ziglang.org/ https://ziglang.org/ Of all the modern systems level programming languages I’ve seen, I like Zig the most. It combines a powerful, modern type system (generics, algebraic data types, statically checked null references) with an impressive simplicity (e.g. without the productivity-consuming and mentally burdensome “borrow checker” of Rust).

bb1234 7y ago
Question: For someone who does not know either Rust or Zig, would you say that Zig also has tools that help the programmer protect from data race conditions (I have read that Rust is helpful in this regard)?
totalperspectiv 7y ago
I have looked at Zig! It looks sweet, but a little to early days for me personally. For example, there's no documentation on how to open a read a line from a file. The best I can find is an example implementation of `cat` in the source repo. I will certainly be coming back to it at some point though.
pcwalton 7y ago
> without the productivity-consuming and mentally burdensome “borrow checker” of Rust The borrow checker also gives you memory safety, which Zig does not have at the moment. Solving use-after-free and related issues is a hard problem. I have yet to see a way to solve it that doesn't boil down to one of runtime garbage collection, not allowing heap allocation at all, not freeing memory at all, or a region system/borrow checking. It's fine to not like the borrow checker, but it's there for a reason.
- pjmlp 7y ago
  Yeah, but currently it still is a roadblock when writing GUI code, to the point that Gtk-rs samples use macros to overcome the boilerplate to access widget data from callbacks.
7y ago

squarefoot 7y ago

"- Crystal: ?; fast?; have not used" Ruby is an extremely powerful language, with the only drawback of being truly slow. Crystal solves this problem with flying colors by offering almost full Ruby compatibility along with very efficient native code generation. Unfortunately it's still young and lacks user base as well as ports to other architectures.

dymk 7y ago
Lacking the Ruby ecosystem means it lacks like, 90% of the reason you’d choose a language.
petre 7y ago
Yup, quite fast. On par with Go. Compiling Crystal is also fast and the language is beautiful.
- bb1234 7y ago
  According to the benchmarks at https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks, Crystal is about twice as fast as Go.
- omaranto 7y ago
  In a discussion involving C, C++, Rust and Nim, "on par with Go" is probably not considered fast. Also, it would seem Crystal is closer to those languages I mentioned than to Go in speed.
jashmatthews 7y ago
>almost full Ruby compatibility Crystal is very different from Ruby. Hello world will copy paste but there are major differences after that.

pjmlp 7y ago

Adding to your list: - Swift: C# like productivity, compiles to native code, however mostly constrained to Apple platforms - Eiffel: RAD tooling, uses JIT for development, compiles to native code via C and C++ compilers for deployment, mostly constrained to enterprises that value correction above all and are willing to pay its prices - Delphi: One of the best RAD tooling still around, with compilation to native code, while allowing all the low level stuff from C and C++; Mostly safe, suffers from manual memory management. Borland mismanagement placed it as enterprise devtool. You can use Lazarus/FreePascal as alternative - Ada/SPARK. Compiles to native. Also enjoys fast compilations. For devs and companies that care about code quality. Besides GNAT all the remaining implementations have enterprise level prices

jamesmp98 7y ago
Ada has always been intriguing to me. Is it used much anywhere these days?
- pjmlp 7y ago
  Avionics, trains, oil rigs, basically everything where human life's are at stake, deemed as High Integrity Computing. Only 4 languages apply, Java with Real Time extensions, C and C++ with certification processes like MISRA and AUTOSAR among others, and Ada/SPARK.

pb82 7y ago

Golang has good cross compilation built in. You can easily build Linux binaries on a Mac. Makes deployment and containers almost as painless as the interpreted/jited languages.

pjmlp 7y ago
Only works for pure Go code.

cshenton 7y ago

Julia is the fastest (in speed achievable in a short dev time) language I’ve ever used. Especially for any scientific computing workloads.

petre 7y ago
Probably not easily embedable on a vehicle though.
totalperspectiv 7y ago
I really want to love Julia. I've never gotten over the startup time, slow string functions, and package manager repl thing. Perhaps I was getting into it at a bad time, right around the time the new package manager was being announced. The whole thing felt very magic... too R like for comfort.
- philzook 7y ago
  The start up times really bug me too. I think the solution might be sticking to a Jupyter/Juno session or keeping a repl open and reloading. https://github.com/timholy/Revise.jl https://github.com/timholy/Revise.jl It is incredible the degree with which small inconveniences can inhibit adoption.
locoman88 7y ago
Bullet-trains are very fast too, but they need rail tracks. C++/C/Nim/Rust/D are all terrain fast

jonathanstrange 7y ago

I have chosen Go for now, after having learned Nim and Rust. I also know Ada, FreePascal, Racket, CL and a bunch of other languages fairly well. Python was never an option, because it's too slow and (subjective opinion) a very ugly language. There were clear reasons why Go was the best choice for me: Pros: - large infrastructure, many third party libraries - good tooling - fast compilation speed - reasonably fast executables (fast enough) - (just) good enough GUI bindings - although it almost failed on that one - automatic garbage collection Cons: - lack of generics - a bit too much verbosity (if err!=nil) - million dollar mistake Subjective assessment of the other languages (for me, and my type of projects - remember, a programming language is only a tool for a certain purpose): - Nim is a great language, but unfortunately seems to be eternally unready for prime time. Lack of complete enough GUI bindings. - Rust is a convoluted language and has no garbage collection. It is marginally better than Ada at the cost of readability, has a number of minor misfeatures, and an unnecessarily steep learning curve. I predict it to have the same complexity or higher than C++ in ten years from now, with all the disadvantages and security issues this brings. Especially macros are a very, very bad idea. (They also count against Nim in my book.) - D is a very good language and on my list of things to learn. Reasons for deciding against it were primarily its nearness to C++ and the express intent of the developers to get rid of garbage collection in favour of some convoluted, needlessly complex borrow checking. (Unfortunately, D also has macros, but they are less obtrusive and less needed than in Rust.) - C: dev time too slow - C++: dev time too slow, too many pitfalls (even if you use just a subset, at some point you will have to deal with esoteric code and bugs that require 40+ of experience to understand); ugly language. - Kotlin: Java VM is out of question, the long-term technology support on some platforms is too uncertain. - Crystal: issues with multithreading (if I remember correctly), lack of a good enough GUI binding. - Java: out of question - I consider it legacy technology, I've used it in the past and found the frameworks to be horrible (too much OOP); ugly language; future VM support too uncertain on some platforms. - Julia: very nice language, fast; it lacked a good enough GUI binding last time I checked, but once it has one, it will be on my list of things to test. - Zig: interesting but too close to C, no garbage collection, only manual memory management. - FreePascal/Lazarus: probably the best GUI support but mostly manual memory management and felt kind of old; basically, I didn't choose it for fear of accumulating too much technological debt. - Ada: probably the static language I like the most, has everything I need, but is pretty much dead - not enough third party libraries, single vendor lock-in, only GTK as viable GUI option, fear of accumulating too much technological debt; it's a pity, because I think it's the best language among those mentioned so far. - Racket: my main language for the past 20 years, I have developed successfully GUI applications with it, large tooling, fast enough, BUT: application startup time too slow, rich text editors too sluggish, GUI slightly too limited, professional deployment can be complicated (by professional I mean with all correct metadata, icons, according to OS guidelines, code signing, sandboxing, etc.), dynamic typing bad. - CommonLisp: probably a good choice for high-tech long-term, large-scale web-based applications like booking systems or scheduling systems; libraries suffer from lack of documentation, executable sizes and memory consumption fairly large, bindings to C/C++ libraries notoriously incomplete or undocumented; dynamic typing bad. Okay, that's it. These are all purely subjective evaluations for the purpose of writing fun, fast, compact, mid-size cross-platform GUI end-user applications. I should mention that in a more professional setting I would probably bite into the sour apple and just go with C++/Qt. But that wouldn't imply having fun, which is one of my goals.

JoshuaScript 7y ago

You'll definitely want to check out ATS[0]. It's a functional, dependently-typed language with performance on par with C(its compilation target), and has a type system and theorem prover that guarantees memory-safe code. [0] http://www.ats-lang.org http://www.ats-lang.org

philzook 7y ago
I am personally very intrigued by ATS, I think it is striving for a truly unique and powerful point in the programming language space, but have extreme reservations about it being ready for general use. Do you consider it ready for adoption, or are bringing it up as a learning exercise?
- JoshuaScript 7y ago
  > I am personally very intrigued by ATS As am I. I'd say this, along with Idris and Agda are showing how useful types can be. > Do you consider it ready for adoption People have written non-trivial software in it[0], but because it hasn't yet reached a 1.0 release, I wouldn't say it's quite ready for adoption. It seems to be more of an academic project for now. [0] https://github.com/xlq/aos https://github.com/xlq/aos

lmm 7y ago

> Essentially there's a class of programs that are performance sensitive, but also dev time sensitive. How do you choose between the set above? (The answer, if there is one, is probably Python, and then optimize the hotspots, but lets pretend we can indulge). Only if you don't believe other languages can be more productive than Python. IME an ML-like language with type inference and good development tools will be faster to work with than Python, at least as soon as you have to edit code (for a script short enough that you can write it out and expect to be correct first time Python might still win). I regard the ML featureset as table stakes for a language these days; while most languages (all serious languages?) have first-class functions, proper sum types are so useful that I don't want to use a language without them. That cuts the list of possibilities down quite a lot: in terms of having enough maturity/popularity for production use it probably comes down to OCaml (which becomes the default option by seniority), Haskell, F#, Scala, Rust, Swift, or Kotlin. D or Nim just don't offer anything compelling that's worth giving up sum types for, and while Swift or Kotlin can more or less equal OCaml they don't offer a compelling advantage. Any of OCaml/Haskell/F#/Scala/Rust is a defensible choice. Haskell and Scala offer higher-kinded types, which are immensely useful once you get used to them. F# and Scala offer decent IDEs/tooling in a way that the others mostly don't. Rust offers a limited form of linear typing, but as a special case built into the language rather than as functionality emerging from a general type system; you can achieve a similar level of resource safety with a rank-2 type trick (famously used in ST) in a language that supports those (i.e. Haskell or Scala). I use Scala for everything these days. Better-than-Python dev time, better-than-Rust type system, Nim/Java/C#/Go/D/Kotlin-like performance, and first-class Java interop (which I consider better than C/C++ interop, because using C/C++ interop makes your whole program memory-unsafe). Bonus of a compile-to-JS implementation that just works with the same code that you can run in your IDE.

gdy 7y ago
"higher-kinded types, which are immensely useful once you get used to them" Could you give an example of such immense usefulnes?
- lmm 7y ago
  All of the problems that aspect-oriented programming tries to solve, but without any reflectioney magic. So for example I have a custom type to represent database operations that need to happen within a transaction; the type system ensures that there will be a transaction boundary around them eventually, but I can still compose together several different such functions and run a single transaction around them all. In theory you could do this with a "command object", but in a language without HKT you'd have to reimplement all the utility functions that make it practical to use those objects (e.g. traverse, which takes a list of must-happen-in-transaction commands and combines them into a single command that will evaluate to a list) and in practice people doing this kind of thing in Java/C#/Python/... give up and fall back to reflection/AOP/metaclasses/decorators, because it's too cumbersome to manage the transaction boundaries explicitly. But then you get things like http://thecodelesscode.com/case/211 http://thecodelesscode.com/case/211 happening. With HKT you can have reusable, generic functions that work on any kind of effect - all the examples on https://philipnilsson.github.io/Badness10k/escaping-hell-with-monads/ https://philipnilsson.github.io/Badness10k/escaping-hell-wit... and more. E.g. a tree structure library will offer a traversal method that can already handle doing an effectful operation at each level and composing together the effects correctly - even if it's an effect that didn't exist when that library was written. That makes it practical to manage these effects/cross-cutting concerns explicitly, which enables fearless refactoring (it's always clear whether you can e.g. reorder some statements without changing behaviour or not), so you need much less test coverage for the same level of confidence which in turn makes refactoring even easier, and you end up with a virtuous cycle where your code stays clear because it's always easy to refactor for clarity.

jsjsjsjsjsjs 7y ago

> - Nim: C/C++ interop is second to none. This is very wrong. There is perfect c interop - you can import c functions using {.importc.} pragma. C++ interop is best i have seen so far. You can use c++ template types! Here is the sample: https://github.com/3dicc/Urhonimo/blob/master/modules/container/hashmap.nim https://github.com/3dicc/Urhonimo/blob/master/modules/contai... Of course it is not perfect. For example if you would like to override c++ method you will have to write a bit of c++ code using {.emit.} pragma. I do not know a single language that could map c++ template types into it's own generic types like nim can.

Leszek 7y ago
"second to none" means "best" ("there is no one it is second to, thus it is first")
- jsjsjsjsjsjs 7y ago
  TIL. Not native english-speaker. My bad.
  - totalperspectiv 7y ago
    You made my point better though! Nim interop is awesome.
detaro 7y ago
"second to none" means "the best".
deleted 7y ago
[deleted]
mhh__ 7y ago
D's C++ interop looks better at a glance. With a simple extern(C++) you can use templates, classes and vtable's are matched up to single inheritance. There is also some experimental work on catching C++ exceptions but I've never tried to use it.

0xDEEPFAC 7y ago

Ada is being actively used by Nvidia in some of their research: https://blogs.nvidia.com/blog/2019/02/05/adacore-secure-autonomous-driving/ https://blogs.nvidia.com/blog/2019/02/05/adacore-secure-auto...

totalperspectiv 7y ago
I have always wanted to look into Ada, but could never see being able to make a serious business case to use it for real things at the moment.
- exhilaration 7y ago
  It's used widely in defense, much less in private industry. The exception is if you write Oracle PL/SQL - that resembles ADA.

bb1234 7y ago

Since you are asking about performance of some languages, you may find this helpful https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks

pif 7y ago

> but also dev time sensitive. What do you call dev time? Time till we have a prototype to play with and refine the idea? Time till we release a quick & dirty version and start counting the hours before the first bug report? Or time till we can ship and forget?

_448 7y ago

Oh! Where did my Pony (https://www.ponylang.io/ https://www.ponylang.io/) go? :)

kitd 7y ago

The biggest dev-time factors in my professional work time are: 1. A (de-facto) standard toolchain, incl pkg management 2. A rich ecosystem of 3rd-party packages. Which sadly rules out a number of languages that would otherwise be very interesting. Without those 2, I can spend hours fighting with implementing code that I know could be done in a few minutes with a more widely-used language.

EvenThisAcronym 7y ago

- D: lightning fast dev time; fast compile times; performance directly comparable to C and C++; metaprogramming capabilities second only to Lisp.