[marmada]

I've been thinking for a while that it's about time a new (maybe jit compiled?) language hits the scene with:

- A simplified/sounder natively integrated version of Typescript's type system - Javascript's easy notation for manipulating objects - None of Javascript's other baggage/cruft - Something akin to go routines

Basically, something with the performance of Go/Java (so there would be no need to rewrite your code once it starts serving millions of people) but the elegance of Typescript.

Not sure if this is similar to your vision of a "next Python" but it feels somewhat similar.

Basically I think right now:

C -> Zig

C++ -> Rust

Java -?-> Go

Python/Javascript --> ???

With native typing we could get a language as fast as Java/Go but with the cleanliness of Typescript.

[BadInformatics]

I remember a few years back when Nim was going to be the next big thing here, but unfortunately it never gained that level of traction. Still an interesting language even without bigco levels of support behind it.

[pjmlp]

> C -> Zig

If dealing with uses after free and lack of bounds checked access in release code is still a fun factor.

> Java -?-> Go

Not at all, unless one misses Java 1.4 with loots of if/else boilerplate.

[cassepipe]

- But huh, if you checked that at runtime compiling un debug mode, and then you compile you compile the exact same code... It should be OK right ?

- I think you're right. C is more l'île a garbage collected C.

[pjmlp]

Big if, specially if you haven't tested all use cases.

It is the same fallacy as C code is safe if everything was checked, while CVEs keep happening.

[jamil7]

Swift would be a candidate and is a great, progressively disclosed language, simple enough for beginners but scales up in advanced features. It’s attachment to Apple puts a lot of developers off but there is a lot of work going into windows and linux support as well as WASM. One issue is compile times right now.

[jshen]

Typescript is not clean because it has to accommodate every crazy thing people do in raw JavaScript.

Having said that, isn’t Deno close to what you’re looking for?

[marmada]

I actually really like TS's type system precisely because it is insanely flexible.

I can write statically typed code that easily shapes & reshapes objects & code that fits functional or object oriented programming styles.

It's a statically typed language that feels dynamic.

Now, if I were to get a version of TS without all of JS's crutches that would be amazing.

Deno is pretty close, but it lacks on performance & is bounded in potential by JS (in some aspects).

[bambataa]

I live in hope that, one day, TS will loosen its links to JS.

Things like `Object.keys` irritate me because they don’t compose well. What would go wrong if TS started supporting `Object.prototype.keys`? Could even be implemented as a rewrite using `Object.keys`.

[jshen]

I’ve been thinking about this, and I never thought of it before. I would love a language that is both dynamic and static similar to JS and TS. but, when the types are provided, use them to compile to fast code, while keeping the ability to do dynamic scripting.

[proto-n]

What do you think of Dart? It's still evolving, but for me it ticks all those boxes.

[nmfisher]

I’m overwhelmingly favourable towards Dart. While I picked it up for mobile (Flutter) dev, I’ve been slowly replacing a lot of scripting/backend work with it too.

It’s the ideal replacement for general purpose scripting and browser work IMO. I can’t recommend it enough.

[miles7]

What’s your opinion on Julia?

[valenterry]

Scala comes very close to that.

[pbourke]

Scala is nowhere near as approachable as Python or Typescript

[valenterry]

Why do you think that?

[benhoyt]

At least when I used it ~2 years ago: an extremely complex type system with a huge learning curve (unless you're going to just write Java in Scala), poor documentation, and a very slow compiler. That's to say nothing of the JVM-based runtime.

[doliveira]

I got really frustrated one of these days because I reached the 20-something limit for fields in a case class and I had to change a lot of my architecture. It was a Spark job so I needed all those fields in that structure.

Not sure if that's because I'm a beginner or if it's just Spark itself, but Scala errors are impossible to decrypt.

[valenterry]

Ah yeah, that was really a stupid limit.

Time to bump Scala to version 3 so that you don't have the 22 case class field limit anymore. :)

See here: https://dotty.epfl.ch/docs/reference/dropped-features/limit2...

[valenterry]

> unless you're going to just write Java in Scala

That is what I mean though - but I would replace "Java" with python here. Just stay away from all the complexity and write python code. It's pretty simple and some people argue it's the better way to use Scala.

[pbourke]

Scala’s implicits, mutable/immutable collection bifurcation, infix/dot syntax interchangeability for method invocations, tendency of libraries to implement their own mini language, ...

[valenterry]

As a beginner, you don't really have to use Scala's implicits or "infix/dot syntax".

Just like how you don't have to use type annotations, generators, decorators, context managers in python.

Same for libraries.

At some point you will stumble upon a library that forces you to understand them or you even write one yourself, but that is not something that stops you in the beginning.

[random5634]

It does.

Go got this right. If you want to read code, contribute to a large code base, folks will be using the features of the language, including the weird ones. Go has kept things very simple (relatively) in terms of core language. Some things were beyond basic (error handling? no generics?) But boy did it make it easier for contribute and understand code.

def Hi() = "hi" Hi() Hi

Yes, those two variants both work?

[ledauphin]

the JVM is an incredibly heavyweight runtime compared to CPython. I don't think we're going to find the next beginner-friendly language coming out of the most professional runtime in human history.

[valenterry]

True, but I don't think that is what the OP was taking about. The language itself is rather independent of the runtime. Scala compiles to native code or Javascript as well.

[pbourke]

> incredibly heavyweight runtime

The apps may be heavyweight, but the runtime was designed to run on set-top boxes 25 years ago.

[jaytaylor]

The JVM is definitely memory hungry (excluding cherry-picked examples such as 'set top deployments' or the Java Ring from the 90s), moreso than any other language runtime referenced in this discussion.