Hacker News new | past | comments | ask | show | jobs | submit login

> crappy tech

What kind of an argument is this?

Not wanting to learn all those things for multiple languages is valid. But "it would take a while" doesn't tell you anything about whether a language is crappy.

The odds are pretty close to 50:50 that the language you already know is the crappier one.




My main point is that developers chase shiny things and "easy to use" is one of the shiniest things out there.

Past a certain point, being usable in 2 clicks is a negative signal for overall tech quality. Most of the really solid techs need some extra configuration. The classic example of crappy tech is the DB tech that listens on 0.0.0.0 after installation, with no user + pass or admin/admin.


> Past a certain point, being usable in 2 clicks is a negative signal for overall tech quality. Most of the really solid techs need some extra configuration. The classic example of crappy tech is the DB tech that listens on 0.0.0.0 after installation, with no user + pass or admin/admin.

Yeah, but the post up there said 2-3 days. That's plenty of time to handle those important details that make a project non-instant.


Here are some benchmarks:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

The Dart implementation seems much slower than the NodeJs implementation and it doesn’t bring anything new to the table? It added null safety today.

Anyone that knows if it has any feature beyond for example what Ocaml has?


To give context, the implementations for the same problem are completely different, e.g. javascript versions uses worker thrreads on 4 cores for most of the examples. To compare actual performance first similar approaches should be used.



Spectral norm is an interesting example because on single thread and without using SIMD, C, C++, Java, Javascript, Swift and Dart shows very similar performance characteristics (5-6 seconds). The loops are tight, there is not much to do for a decent compiler. it almost pure simple 64 bit floating point arithmetic.

Then you add multi-threading, and see a decent improvement, e.g. from 5 seconds to 1.5 seconds on 4 cores (almost all implementations show a similar gain)

And some languages with support for Vector operations further improves this to 0.7s

So this benchmark seems to be not very useful for comparing performance of any decent language. It could however be used for comparing improvements of using different techniques to solve the problem, or to showcase what new features brings to the table.


> … not very useful for comparing performance of any decent language.

Saying "any decent language" assumes we know without measurement the very thing that we need to measure.

Showing "very similar performance characteristics" is a valid outcome.


> worker thrreads on 4 cores

So how different are the "busy" measurements?

To understand actual performance first understand what approaches were used.


Uuh the benchmarks in this site is very misleading (for all languages). Do your own tests otherwise the numbers there are practically meaningless.


Yes, when others have not written the programs you would like to compare — write your own programs to compare.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

How programs are written does matter.


Of course it matters, What I am saying is that; here is a program written in language A, which uses all the tricks in the book to solve this particular problem, here is a another one written in language B, it uses a completely different technique / algorithm and isn't optimized to death. How is it valid to make a decision about performance if implementations and restrictions are wildly different? So to me the site offers very little of value and I can not take any comparison from there seriously.


> … if implementations and restrictions are wildly different?

What if we can all see implementations that are not wildly different?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...


And as I explained on a different comment, performance of many different language / compilers for this particular benchmark are almost same "If" they use the same technique ( C, C++, Java, Swift, Javascript and Dart.)

But the argument here started as "Hey look language A is faster than language B" , while pointing out completely different implementations, which is, absurd.


> … while pointing out completely different implementations…

danielscrubs referenced measurements which showed similar performance for Dart and NodeJS programs, but did not mention that similar performance.


> … some benchmarks … seems much slower …

nbody dart 8.44s nodejs 8.37s

regexredux dart 4.89s nodejs 4.79s

Those don't seem much slower.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: