Hacker News new | ask | show | jobs
by oblio 1930 days ago
Syntax, semantics, code organization and best practices, libraries, frameworks, debugging and debuggers, IDE support (preferably multiple IDEs for multiple platforms), LSP support, linters, profilers, disassemblers, dependency license checkers, dependency vulnerability scanners, package managers, package repository with support for private repos and proxying/mirroring, should I go on and on and on?

Your toy app takes 2 days to create and then you (or worse, someone else) have to support the crummy Visual Basic/PHP/Javascript/Mongo/ColdFusion/insert easy to use crappy tech here, forever.

4 comments

> 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/...

> … 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.

I think in the framework of choosing boring things, you are spot on. However, all innovation tends to be ten steps forward and eight steps back, so the way that I look at it is simple. For a given effort, are those two steps forward worth the total long term cost? Maybe, maybe not. Usually not, but... people are going to do silly things.

I look at flutter as a quick way to bootstrap a simple CRUD app, but... for what? How does it improve on the web? Not 100% sure, but I do like the down chain investments that flutter supports like Skia.

I'm a huge fan of canvas, but I recognize its limits for building apps. It's great for many things like games, and it is a 2D escape hatch. I'll admit that I get suckered into the lure of building a 2D canvas empire that is cross platform because it would be nice.

The fact is that even considering all those points, Flutter+Dart is still much easier to learn than Swift+iOS and Kotlin+Android (even separately). And I'm not even considering Desktop.
Sure, but you also get really powerful ecosystems with those languages. Which can't be said about Dart + Flutter, where most of those packages are amateur quality.

> Desktop

JetBrains Compose.

have you actually tried it? its ecosystem provides all of that