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

This so much! Go would be a great language if it had generics and no "interface {}". I'd use that over any flavor of Rust any day.

D is pretty much the opposite of Go, a pinnacle of feature bloat instead of stripped down simplicity. A C++ killer that turned into a kind of C++ with GC.

Go would be have an interesting language in 1986 [0], or in 1995 [1].

As it stands, it is forced to follow some of Java design mistakes by not integrating modern features and then being forced to actually adopt them in a half-baked way due to market pressure, while striving not to break backwards compatibility with existing code.

Modern C++ also uses GC, even it is opt-in.

And several modern C++ features actually originated in D.

D has the benefit of not being constrained by C copy-paste compatibility like C++.

But yeah, it suffers from having a tiny community.

[0] - https://en.wikipedia.org/wiki/Oberon_(programming_language)

[1] - https://en.wikipedia.org/wiki/Limbo_(programming_language)

> But yeah, it suffers from having a tiny community.

And feature bloat.

Being a modern language not stuck in the 60's language design is not feature bloat.

Orthogonal concepts.

Modern languages can be bloated.

Or stuck in the pre-history of language design.

If Go's design was perfect, its eco-system wouldn't feel like Java 1.0, full with libraries to replicate what should be language features to start with.

The first time I saw "go generate" it was on Borland C++ 2.0 for MS-DOS, released around 1990.

Can't lie. It's entertaining to watch people like you get emotional over a piece of technology.

Not really, passional about language design and safety, indeed.

Some of us care about advancing the state of art, instead of being stuck into the ways of the past.

There it is. :)

You may, or may not, be aware of this - https://blog.golang.org/why-generics

I believe it's still in the roadmap for Go 2.0

Zig's comptime is a very simple and minimalistic but still incredibly useful and strong approach to generics. I think that could fit into a language like that. I many ways I find Zig as keeping the minimalism trait that Go has (which they both take from C). But I get that people want a gc sometimes.

Zig is beautiful, I'm having high hopes for it.

I'm curious what the next big language iteration will bring. It's been a while that I got excited about a new language, last time was probably C#, but that's 20 years ago... Crazy, that there hasn't been any new language revolution sort of how Java was one. But maybe I should look more into new things like Julia, but they seem a bit niche.

I hope the next big programming language will be one that is split into two language-variants: the "low-level-variant" and the "high-level-variant".

The high-level-variant is a dynamic language with optional typing, which is good for scripting, fast prototyping, fast time-to-market, etc.

The low-level-variant is similar to the high-level-variant (same syntax, same features mostly, same documentation), but it has no garbage collector, typing is mandatory and it runs fast like C/C++/Rust. Compiled packages that are written in the low-level-variant can be used from the high-level-variant with minimal effort or without additional effort at all. The tooling to achieve this comes with the language.

Proponents would say that julia is both languages at the same time

Yes, and I think Julia is a perfect starting point for an extremely productive general purpose language.

The one major wart with Julia is reliance on GC, I'm interested to hear what workarounds exist. If no common usage patterns rely on the GC, it should be possible to write "recycling" code that doesn't incur GC pauses and hence, unpredictable latency.

I really enjoy using Julia, it's a great balance of concision, expressiveness, and performance.

There is a common demand from people for extracting just a very concrete computation from a julia codebase and compiling it to a standalone library (or even just using it within an existing julia program, but guaranteeing certain allocation or real time behavior). For example, julia includes a pure julia implementation of libm, but we also maintain the openlibm C library, since we link it into some of our C dependencies that need good quality math functions. It would be nice just to compile the julia version and have it be a drop in replacement for the libm that can be linked. Of course for that you don't want the runtime, or GC or code generator. The challenge here is coming up with the right interfaces and abstractions to make this a feasible and useful thing, without splitting the community into those that care about it and those that don't. We've started some work in this direction, but it isn't really usable yet.

This sounds amazing and exactly what people have been clamoring for. Extremely excited.

I think it will also rocket up Julia's popularity and usage not just for ML but as a general purpose language

Looking forward to have this capability in Julia.

Is some concept of language support for traits/ interfaces and/or static typing part of this effort?

Also, would there be different levels of leanness for the static compile? I can see some people wanting binaries that use a minimal runtime or GC, but no heavy JIT etc so that a larger set of programs can be distributed but at some tradeoff.

AFAIK, Julia has a garbage collector. I envision the thing more like a rust split into two variants. One with GC and mandatory typing, one without.

Yes, for sure my suggestion was an incomplete answer, but still you would want the lower language be GC-aware/GC-compatible so I am not sure what the advantages of having two languages would be compared to having a GC language that can have non-GC modules/functions.

We also have an example of something more similar to what you are asking with Javascript+wasm (or better Typescript+wasm). I think they are both a fertile ground for future growth.

While it's not exactly there, this kind of describes Ruby and Crystal.

I believe the next evolution will be to combine Rust and Lisp; a programming language as flexible as LISP without giving up the safety of Rust, including a typesystem that can be entirely coded in the language itself, safely.

I have something similar in mind: I want to have homoiconicity but with typed data underneath (instead of just untyped lists) in order to add some structure and let compiler help you with macros. That plus advanced type system with gradual verification. I'm in early exploration phase, but I have some ideas written down: https://github.com/krcz/zygote .

> a typesystem that can be entirely coded in the language itself

The closest thing to this I can think of is Racket. It's supposedly powerful enough to embed Haskell in it https://lexi-lambda.github.io/hackett/

It's about the ability, not the reality. As Racket, the base language can have no explicit rules for any type systems to be embedded. There can be more powerful candidates, e.g. Kernel: https://web.cs.wpi.edu/~jshutt/kernel.html.

Racket is special because its designers provide dedicated support of language-oriented programming. But that is about ecosystems, not typesystems.

I would imagine something closer to rust in terms of base and then being able to put Haskell on top without loosing any safety guarantees. Or possibly even allowing an arbitrary type system as long as you can prove it's sound with the guarantees of the language.

Types are closed terms of contracts encoded in a language within specific phases. If you really need any guarantees without further knowledge shaped before running, then, besides the typechecking, the typing rules should also be programmable by users (rather than the language designer) for the sake of providing proofs. The base system must practically have no mandated static type systems at all, which is far from Rust.

I would disagree, you need a solid typesystem and then any other typesystem must prove to be a compatible superset.

Rust’s macro system gives you this already. Is there something you see it not providing that the language you’re imagining would?

Rust's current macro's aren't as powerful as I would like them, and procedural macros are far more difficult and extremely hard to properly develop and debug.

The substitution macros aren't that much fun either since they lack certain capabilities (like introducing a new variable into the current scope without having to specify the name redundantly).

Without a lot of external libraries, procedural macros are almost impossible to write in my experience.

Neither of them allows one to properly code onto the type system or replace it and neither is properly supported by the IDEs (or RLS).

rust proc macros are limited because they need to be in a separate crate and syn is also not that much easier to work with, it's too level IMHO

I'd like to be able to hide Future, Vec, Result, etc. behind a trait.

Go is garbage.

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