Ask HN: What language will you pick if you are to reinvent the data ecosystem? • Hacker News Board

Re: Ask HN: What language will you pick if you are to reinvent the data ecosystem?

#21

Post by mikewarot » Sun, Jan 23, 2022, 7:28 PM UTC

I'd meet up with Alan Turing in 1950, and give him a modern desktop with Linux and all the languages loaded, and Wikipedia.

I'd do everything I could to help him avoid his fate, and all the politics of the 1950s, etc.

Then I'd give John McCarthy his machine, and as him to finish the system that Lisp was the intermediate language for.

Then on to visit Feynman. I'd of course give him a computer as well, and ask for his help building a time machine to get me home. I'm sure he'd get a second Nobel out of that effort.

Re: Ask HN: What language will you pick if you are to reinvent the data ecosystem?

#22

Post by [deleted] » Sun, Jan 23, 2022, 7:44 PM UTC

jsskodof wrote: post #13

fault1 wrote: post #12

I would say there isn't a completely ideal language yet. Perhaps if Julia and Typescript had a baby: gradual typing structural subtyping multiple dispatch interfaces with declaration merging

If Julia and typescript had a baby, that baby would ideally be a lot like Julia and nothing like typescript.

[deleted]

Re: Ask HN: What language will you pick if you are to reinvent the data ecosystem?

#23

Post by fault1 » Sun, Jan 23, 2022, 9:44 PM UTC

jsskodof wrote: post #20

fault1 wrote: post #17

Earlier quoted context omitted.

Why? I'll give you my two cents since I've tinkered with both languages extensively (tho I mostly write Python or C++ professionally, and Scala in the past). I'd say TypeScript has a lot of things that are missing from Julia that are very useful for "data" oriented usages. And vice versa, Julia has a lot of numerical and metaprogramming stuff that is missing or nacient from the JS ecosystem. I would say that TypeScri…

I notice you didn't mention any specifics, other than typescript can manipulate jsons - so can every other language in the world (and jsons are _horrible_ for data anyway)

JSON like it or not, is the world's most dominant data exchange format, so much so that processing JSON is a not so insignificant part of all data center CPU cycles.

Julia has one good library for this (JSON3.jl), but it really should be embedded in the language.

Furthermore, Julia has very nice support for multi-dimensional arrays, but it's built in support for dictionaries/hash maps isn't very good, and they might be more prevalent in many types of data processing (certainly in many "big data" types of workloads). There is another third party library for this (Dictionaries.jl) but once again, in practice, JavaScript and TypeScript not only much faster and more optimized for this, but also have better tooling available out of the box.

Again, not a knock on Julia at all, it's great for certain things, but it's important to understand where the ecosystem has gaps are and where things can be learned from other ecosystems.

Re: Ask HN: What language will you pick if you are to reinvent the data ecosystem?

#24

Post by muzani » Mon, Jan 24, 2022, 12:53 PM UTC

smt88 wrote: post #19

muzani wrote: post #7

Earlier quoted context omitted.

Kotlin?

Maybe. I think you need something with the syntactic flexibility to work well with different types of data. I would have to look closer at Clojure and Scala.

It's almost exactly the same as Java, but much more compact. Java fans say Java has evolved to match Kotlin and they're probably right. But it's just faster to type ? instead of @Nullable.

Re: Ask HN: What language will you pick if you are to reinvent the data ecosystem?

#25

Post by smt88 » Mon, Jan 24, 2022, 3:45 PM UTC

muzani wrote: post #24

smt88 wrote: post #19

Earlier quoted context omitted.

Maybe. I think you need something with the syntactic flexibility to work well with different types of data. I would have to look closer at Clojure and Scala.

It's almost exactly the same as Java, but much more compact. Java fans say Java has evolved to match Kotlin and they're probably right. But it's just faster to type ? instead of @Nullable.

> Java fans say Java has evolved to match Kotlin and they're probably right.

It definitely adopted a lot of the good things in Kotlin, but Kotlin doesn't have the problem of needing to maintain backward compatibility. Kotlin doesn't even natively have null, which (in my opinion) is the best thing about the language.