Hacker News Reader

Comment by ano88888 | Hacker News Reader

Why can't we have a language easy to read and maintain but also have the speed of C?

It's not "the C part" that makes code run fast, but memory access patterns. C just happens to not get in the way between the coder and the machine when it comes to explicit control over memory layout. In the late 60's and early 70's this was probably an "accidential feature", but with the widening CPU/memory performance gap it turned out that later languages (from the late 90's and early 00's) had bet on the wrong horse by trying to abstract memory away. More recently this trend is reversing again and plenty of C alternatives are starting to appear with explicit control over memory layout (Zig, Nim, Odin, Rust, ...).

Doesn't Rust mostly abstract the memory management away as well? It tends to be low overhead, and has sensible defaults with respect to memory management, but it's built around RAII and for instance if you use a lot of reference types as far as I know there's nothing keeping you from having fragmented memory the same way you would with another high level language.

I know Rust also offers arenas and other purpose built tools for more optimized allocation strategies, but Rust doesn't seem like the language you would reach for if your number one priority is memory performance.

It seems like there is a necessary trade-off between truly top-end memory performance and memory safety.

Well yeah, you can write slow code in any language if you don't think about memory layout ;) I see Rust roughly in the same bucket as C++. You can abstract the details of memory management away - which mostly also means giving up control over how things are arranged in memory - but if needed the low level explicit memory management features are there.

I guess the difference is that C++ still gives you pretty much direct access to memory (i.e. pointer arithmetic). Rust tries very hard to keep you at arms length from the actual memory as a rule, and forces you to work through a safe abstraction unless you use an escape hatch.

If by "escape hatch" you mean unsafe blocks, then whole C++ is an escape hatch.

One of the big differences memory-wise between the C/C++/Rust family and the Javas of the world is having first class support for by-value object types (and collections thereof).

Yes, you can trash your cache in all these languages if you choose to do everything with references to a multitude of individual heap allocations... but in Java-likes you don't have the choice not to do that

So a good language, should not abstract that memory pyramid away, but instead make you painfully aware of it, while developing. Rewarding DOD, punishing OO, but that results in more education time for programers, which no company is willing to pay for.

What instead is needed is a intermediate language, that takes the constructs of object orientation and the instruction flow and allows to rearrange them for maximum memory efficieny. Like, strip those OO-bjects into arrays, or directly pack them into hot-loop structs that have little regard for the Objects they started out with.

Can someone from the old guard tell me, how often we have been here in the language design cycles through the desert?

> that results in more education time for programers, which no company is willing to pay for

That's why you finally stop teaching Java in high schools.

I was going to say OOP aside from the basic animals and calls example, takes years of indoctrination for people to find it the simple default way to do things.

Functional programming is much simpler, but we don't spend years hammering the concept into people's brains.

I program Java to earn my living and any hierarchy deeper than two is a bad smell for me. Not that it cannot have its place, but most of the time you're right, some find so fascinating to inherit everything from everything...

I remember sitting in these lectures thinking, why not just use a function without all the boilerplate? And a decade later the programming world finally came back to some semblance of sanity.

Because for some reason most OO learning material seems to be focused on syntax and language features, not design. It's a real shame.

Ah yes, functional programming is indeed so much simpler.

I'll just use a Kleisli

With helping acquaintances learning programming from 0, I have a sample size of n = 2 that starting with FP got them to grok basic programming within a very short amount of time.

And IME moving from FP to OOP is MUCH easier than the other way around.

Don't really have the knowledge to compare iterative vs functional for a complete beginner, though I suspect that even there moving from FP to iterative is easier.

> Like, strip those OO-bjects into arrays, or directly pack them into hot-loop structs that have little regard for the Objects they started out with.

I think Jonathan Blow's JAI is trying to do something like this. Unfortunately it isn't exactly available yet, or it wasn't last time I looked.

I believe that the direction of a managed language with value types is a good goal.

I especially like Java’s plan of introducing them: according to the latest design iteration, there will be 3 buckets of objects: current identity-having ones, value classes and primitive classes.

The second category would drop identity, but will keep nullability (for example two DateTime instance of the same value will be considered equal on a VM-level, allowing for optimizations like allocating DateTime’s inside an array serially, or stack-allocation. Nullability is important because there is no sane default value choice for for example a DateTime. But this value can be encoded cleverly similarly to what Rust does with optional)

The third category will loose nullability as well and current primitives will be migrated to it. So a ComplexInt “class” will be possible to implement with “zero” overhead.

My point being that there are two ways of improving performance, either showing more knobs to manipulate, or to raise the abstraction level, allowing cleverer optimizations. C# does the former, while Java never went that route, and I think that the latter approach better fits a managed language and can easily push it for like 90% better performance at a fraction of developer complexity.

Just allocate the objects in the stack, RAII style.

Jai has this as an explicit goal.

Zig has closely aligned goals.

It's not even just memory access patterns. It's any and all abstractions - C doesn't provide any, so you write things manually, and thus won't do things that are not required for your use-case (whether it be separated loops for actions, pre-initialization/zeroing, multiple allocations where one or none could do, and higher-level stuff like no need for iterator stability, a vector push that assumes reserved space, etc).

Well, lack of abstraction can easily hinder performance as well. Just compare C’s string management story with that of C++. (Also, for very performance-oriented workloads, C++ will be preferred). In case of C you only have dumb c strings, on which you will iterate many many times completely needlessly. It is both error prone, and less performant than C++’s strings, which can do small string optimizations (storing the string inside the structure if it fits, and being a pointer to it otherwise).

I'd say the case of C strings is more a case of a bad abstraction C has (at least historically), rather than lack of one. But the things that expect them are just the standard library (which doesn't have many useful general-purpose things anyway), so you can write your strings as a pair/struct of char*+length or whatever else you may want just fine.

Small string optimizations, while nice (and probably do average out to being beneficial), aren't always needed, and the extra generated code for handling both cases could make it not worth it if you've got a fast allocator, and can even make some operations just outright slower. (and if your code doesn't actually have strings anywhere near hot loops, all you get is a larger binary). File paths, for example, are often large enough to not fit the small case, but still small enough where even the check for whether it is small can be a couple percent of allocation/freeing.

Being error-prone, though, is something that I can agree with. That's the cost of doing things manually.

(I'd also like to note that malloc/free are a much more important case of a bad abstraction - they have quite a bit of overhead for being able to handle various lengths & multithreading, while a big portion of allocations is on the same (often, only) thread with a constant size, and said size being known at free-time, which is a lot more trivial to handle; not even talking about the cost of calling a non-inlined function spilling things to the stack)

Well the reason this one may be a good example is that you couldn’t do this optimization in C even if you wanted to. You would have to call a function at every use-site to handle your “abstraction”. And the same thing applies in other cases.

Also, I’m not sure the added conditional branch will increase the binary too much, and the reason it is inside the c++ stdlib is that it was likely measured and proved beneficial.

But I do agree that maybe your allocation example is a better one, though the solution to that is perhaps a full GC, which does have a few tradeoffs (which are worthy to take more often than not).

Right; making abstractions in C when you really know you should can be messy, but still possible (not with the same syntax, but I personally like the fact that a[b] is 100% guaranteed to be, at most, a single load; similarly for all operations other than function calls; makes it easier to reason about performance at a glance).

Recommending a GC is hard for me though; over your system malloc/free, maybe, but alternative allocators can be very fast, without the drawbacks of pauses (or slower execution as a result from a non-pausing GC).

Go fills that spot for me.

I've done video4linux stuff in Go, and passing an unsafe.Pointer to a Go struct in an ioctl() worked fine, which tells me that Go structs are isomorphic to C structs. Even though Go has garbage collection, it allocates everything it can on the stack, so only long-lived shared-between-goroutines objects are subject to garbage collection.

Go abstracts concurrency, completely removing all concurrent features from a language except for the "go" keyword (that launches a goroutine - which is basically a tiny virtual thread), channels (which are selectable queues) and "select" keyword that waits for the first "input" from a static set of channels.

Go strikes me as one of the best "good enough" languages we have right now. You're not going to do HPC in Go, but it's performant enough to run circles around a lot of high level languages and dynamic languages. It abstracts away the stuff that's super error prone about manual memory management, and it's so brutally simple that it's hard for one of your colleagues to write code you're not going to be able to understand.

There's a few features that could improve it, like proper ADT's, and it's a bit lacking in expressiveness for me to choose it for personal hobby projects, but I would recommend it any time for general-case professional software development.

> but it's performant enough to run circles around a lot of high level languages and dynamic languages

It ain’t running circles around any managed language, with perhaps the exception of Python.

C#, Java, JS all have comparably good performances, sometimes much better - e.g. when GC can’t be avoided.

Go is in my experience significantly faster than Java, and uses an order of magnitude less memory for equivalent functionality.

If you have any data (or better yet, benchmarks I can run on my own machine), I'd very much like to see some hard numbers.

Go can be faster at small, specific programs where memory lifetimes are deterministic and you can use value types. Otherwise, Java will beat every other managed language by a huge margin when it comes to GC-related workflows. Sure, it does so at higher memory usage, but that is a good tradeoff for many use-cases (especially server).

Benchmarks are hard to do right but this one does actually measure GC quite well: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (For managed languages. It is not really a fair comparison between non-GC and GC-languages)

So all in all, for bigger programs it is hard to do a good comparison, but there is exactly where JIT compilers shine and the memory tradeoff and the like brings their return.

Isn't a lot of server code these days small programs that just pull data out of a database and feed it to an HHTPS response?

It seems like it's a pretty good option to have your infrastructure code implemented in a systems programming language like C or Rust (probably AWS or GCP is doing this for you), and just implement your business logic in Go as the type of small, well-defined programs you're talking about.

But then why go? You can also implement that logic in a likely much more readable way in Python (as at that point performance doesn’t matter), or just write the whole thing in Java/C#/Scala/Kotlin whatever, which in my opinion are more expressive for business logic.

Go is much faster than Python, uses less memory, and compiles down to a statically-linked native binary, making containerization trivial. And (IMHO) it's even more readable than Python - nowdays Python code is as easily turned into an unreadable mess as Java or C# code. Just try reading Python standard library and Go standard library - the difference is monumental.

We are talking about business logic. The infrastructure is already in a lower level language, so the performance is not a concern.

And we will have to disagree on C#/Java/Python being unreadable mess. In my experience all 3 can be written in a really well maintainable way. I don’t have much experience with Go, but out of these, I would vote for it as the least maintainable (as just because each line is trivial to understand, doesn’t make the whole program flow easy to read. Otherwise why not just write assembly, every line is even more trivial there)

Performance is always a concern. For instance, if running a python interpreter introduces latency for each request, that can add up to perceptively worse performance when applied throughout a product.

> In my experience all 3 can be written in a really well maintainable way.

That's true, but that is generally true of any (non-toy) language. But in the modern world of rapid development, it matters how hard is it to write code in a non-maintainable way - i.e. how well it tolerates modifications by different people. And to me, it seems easier to write readable code in Go than it is to write unreadable code.

It seems to come from the lack of features - Java, Python and C# have too many features, and any problem can be solved in N different ways, each one with its own warts. If you want to work on a wide range of codebases, you have to know each one of the approaches and their warts and footguns.

Meanwhile, Go feels like it really reached the "there should be one obvious way to do it" ideal of Python, while Python has over the years evolved into something more Perl-like. Want to build a concurrent application? Chose your tradeoff - either you get CPU scalability (multiprocessing) but lose memory sharing, or you get a simple concurrent model (threading) that isn't scalable, or you get I/O scalability (asyncio) at the cost of function coloring, error-proneness and a single-threadedness. Go solved the whole thing with the goroutine model - internally it multiplexes coroutines onto a set of OS threads, but all blocking calls are wrapped by Go runtime which makes every coroutine behave and feel like an ordinary thread, without the massive memory use of OS threads.

Could you expand a bit on why do you think Java has too many features? It is a very small language, that is often berated because it picks up features way too slowly if anything.

I would go as far to claim that Java is an easier language than Go, or at least in the same ballpark.

> Could you expand a bit on why do you think Java has too many features?

I think you're asking for technical details, but I'm afraid I don't know Java well enough to do an objective comparison. I'll try with a subjective explanation or why I think so.

I've learned Go in 20 minutes following the Go Tour. Few months later, I feel like there isn't a single thing I don't know about Go. It's dead simple. When I open a Go repository, it's easy for me to get into the codebase, as all code is more-or-less the same.

I've learned Java back in high school, and to this day I don't feel like I "know" the language. I've tried reading some Java repositories, and every time I feel like there's some kind of friction - some implicit knowledge about it that I just don't understand.

Maybe it's just me, and I haven't spent enough time learning Java. But then again, I've spent even less time learning Go, and yet I have a much easier time using it. That's what I mean by "a very small language".

The number of ways to write something is only very loosely correlated with maintainability. The ease of maintenance is IMHO more a function of how much information about the properties of the code you can easily read from the text, and how well the abstractions in the code map to the abstractions you'd use when describing the solution to a friend. Lack of features doesn't help in that regard. That's why probably Go has just added generics, despite the long tradition of Go promoters claiming "lack of generics is a good thing" ;)

Languages with very little type information, e.g. dynamic ones, tend to be quite hard to maintain, unless the original developers kept the discipline of good naming and verbose commenting. Go and Java with their somewhat static, but limited typing and elements of dynamism (interface{}, Object, reflection), sit somewhere in the middle between PHP/JS and Rust/Scala/Haskell.

Languages with little expressive / abstraction power, so the ones limited in features or low-level are also often hard to maintain, because you have to reverse-engineer the high-level stuff from all the details you see. Take assembly as an example - while it may be quite obvious what the program is doing at the bits and bytes level, understanding the sense of that bit-level manipulation may be a much harder task. The assembly language might actually be very simple, but that does not help. I remember when we had a MIPS class, the whole specs was just a few pages, could be learned in an hour.

In my experience, Python is far less readable than languages like go. The information density and semantic whitespace of Python really hurts readability.

How does the whitespace hurt readability when basically every styleguide and linter in other languages indents code blocks?

Wow, I had no idea that java was so fast. One thing I like about go is that you can cram many thousands of concurrent requests into the same process. But it looks like java has some pretty robust async tools... So I bet you could do something similar

The JVM is a real beast, which makes sense as a good chunk of the whole internet runs on top of it (almost every big corp has plenty of infrastructure running Java), so it had plenty of engineering time poured into it.

Regarding concurrency, I wouldn’t choose existing reactive frameworks and what not for a new system. Java will soon get Project Loom, which will introduce Go-like virtual threads - so that one can write a web server that spawns a new thread for each request as well. Since the Java ecosystem is very purely written almost exclusively in Java itself (no FFI), basically everything will turn automagically non-blocking.

You picked binary trees, which has java better than Go, I'm guessing something about the implementation.

If you look at other examples on that site, Go and Java are roughly the same, but with some variance:

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

> … guessing something about the implementation.

The source code is shown —

    binary-trees Java #7 program

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

    binary-trees Go #2 program

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

Alright, I guess I'll admit this just sniped me.

Having read the rules it's difficult to know what's considered "fair" for this test - all GC tuning is off the table, sure. But what's bugging me is "Leaf nodes must be the same as interior nodes - the same memory allocation." So what constitutes "the same memory allocation" - literally the exact same call to some opaque internal allocator? If so, shouldn't Java also have to disable JIT to be fair?

Let me offer an alternate interpretation: I will do the same memory allocation if I need to allocate a node, but if my language lets me not allocate a node yet still use that node why should I? Or an alternate argument if you don't like that one: Why must my "node" be `Tree`, rather than `*Tree`?

A central idiom of Go is that zero-values of a type can be useful; a two-line change, no new special-cases, no pooling or such gauche hacks:

    // Count the nodes in the given complete binary tree.
    func (t *Tree) Count() int {
     if t == nil {
      return 1
     }
     return 1 + t.Right.Count() + t.Left.Count()
    }

    // Create a complete binary tree of `depth` and return it as a pointer.
    func NewTree(depth int) *Tree {
     if depth > 0 {
      return &Tree{Left: NewTree(depth - 1), Right: NewTree(depth - 1)}
     } else {
      return nil
     }
    }

I'm sure someone will tell me I "optimized away the work" - but in the end I believe I'm making exactly the same number of method calls on the same type of receiver. If that's not the work, what is?

And then the Java etc programs are re-written to do the same and the test value is increased (to compensate for the reduced memory allocation) and we're back where we started?

Seems like moving the furniture around.

No doubt I've misunderstood.

A null value in Java has no methods / is not an object. I didn’t precompute anything.

afaict you're making a distinction without a difference.

afaict the Java etc programs could be re-written using null where you used nil — please explain why you think that isn't correct.

You cannot call a method on null. Meaning:

- Practically, Java would rather have to `return 3` when it detects a null child, effectively precomputing the penultimate level.

- Semantically, Java could no longer distinguish between an absent child and a child with no children.

Honestly, I have other variants that still don't use pooling but are less idiomatic; I find this exercise is begging the question hard. Any tools, however idiomatic, the language is giving you to reduce the effects of allocation seem to be off-limits for GCd languages. Whereas then e.g. C can just throw them all in a third-party pool library. And JIT languages are presumably allowed to fuse anything they want.

I think you just said the Java etc programs could be re-written in a similar way?

And we could add some more rules ("distinguish between an absent child and a child with no children") to reject those Java etc programs.

> I think you just said the Java etc programs could be re-written in a similar way?

I could rewrite the Go program to return 3 too, but I doubt you’d accept that.

I can only conclude the benchmarks game is bad-faith bullshit at this point.

> … bad-faith bullshit…

Kudos for actually bothering to "read the rules".

None for ignoring what you read.

The answer to "… but if my language lets me not allocate a node yet still use that node why should I?" is — Because allocate a node is the basis of comparison with the other programs!

Change that for the Go programs and you change that for all the other programs; otherwise just special pleading for Go lang.

He said "easy to read" not "filled with weird syntax choices that make anyone from a C background barf". What the hell are those channel arrows and why do they point the wrong way.

Channel arrows are basically just read/write operations.

If `ch` is a channel, then this expression means "value obtained from reading from the channel":

    <-ch

And this expression means "write value x into the channel":

    ch <- x

Both expressions can be used as a case inside select statement:

    select {
    case val := <-ch:
        // ...
    case ch <- val:
        // ...
    }

Which will execute exactly one case, depending on which channel becomes "ready" first - channel is ready for reading if there is another goroutine blocked on a write operation, and ready for writing if there is another goroutine blocked on a read operation.

You say you're from C background - if you've ever worked will file descriptors you will notice that channels are basically userspace file descriptors. Channel reading and writing is isomorphic to read() and write() syscalls, and select keyword is isomorphic to select() syscall.

Hopefully this clears up the whole channel syntax thing. I just hope you weren't trolling.

> Channel reading and writing is isomorphic to read() and write() syscalls

This is a very bad mental model because channels operations cannot be canceled (without using select on two channels) or return any error status (at all).

While technically true, I don't really see the impact of the difference. It is idiomatic to use contexts for any kind of cancellation during channel operations, and it works well.

The syscall comparison was made to give intuition about general behavior of channels to someone with a background in C. Of course it's not completely identical.

The ability of read/write to communicate via errors as well as the actual data transferred is significant - there's a reason Go's i/o model is io.Reader/io.Writer and not chan []byte.

You might as well explain channels in terms of any blocking operation if the bar for "isomorphic" (now backtracked to "intuitively" I guess) is that low.

I don't know what's the bar for "isomorphism", but I know that the word literally means "same shape", so just because some nerd that got killed in a duel over a girl used the same word in a mathematical context doesn't give him dibs over its general use.

Unless, of course, system calls can be modeled as operators over sets. In which case, please tell me how.

In normal use of the term, a function's shape is its type signature; at the very least its in and out arity, and usually even more specific.

Well, in my case I used it to signify same behavior in terms of process/goroutine communication. I think it's "specific enough" to warrant the use of word "isomorphic".

It was a rhetorical question.

So you were trolling. Bummer.

Rust is that if you keep the code simple without too many trait objects and macros and type magic. But then it becomes even more constrained than it actually is. It'll also be boilerplate heavy and hard to write.

Julia is fast, easy to read, and easy to write. But it's not easy to maintain. There is a direct tradeoff between dynamism on one hand making things easier to read/write and static enforceability on the other making it easier to maintain.

Haskell has an elegance, and can be written as simply as C. Usually fast enough, and can be optimized as well. The downside is that you will be sucked into a rabbit hole of academic type theory and wonder how best to express your system as a Free Monad instead of bashing it out like any sane C programmer. Just kidding, someone already figured out those hard parts for you, you just forgot to browse for it on Hackage.

It's a fair criticism of Haskell that you can fairly easily blow up your time/space complexity without realising it though. I think in many ways it's better but Haskell specifically demands a lot even for a functional language.

Pascal dialects, Modula-2 are of a similar age, while other like JOVIAL are a decade older but they did not come with a very big killer feature, an OS like UNIX.

Then there were BLISS, Mesa and PL/I, but the OSes that made use of them lost to UNIX, so.

With exception of Mac OS, written in Object Pascal and later ported to a mix of Object Pascal and C++.

Having said this, plenty of alternatives with AOT compilers exist nowadays.

The only thing C has going for it, is historical weight, UNIX/POSIX ecosystem, and some domains that are closed to any alternative suggestions, due to tooling or cargo cult against alternatives.

Because "easy to read and maintain" is about humans, and "speed of C" is about machines, and there is a vast gulf between the 2 that always force you to compromise in one or the other to get the 2 together, and usually both.

Code being easier to read and maintain is a function of how close it is to human semantics. The more the algorithm is presented in terms and notations humans like and find familiar, the easier. Code being performant is a function of how close it is to machine semantics, the more the algorithm is presented as steps that the machine likes and finds familiar, the faster it will run, as the machine is doing less to execute each step.

There is a fundamental tension between the 2, even if compilation from high level languages might, at first glance, give us the illusion that we can have both. We can't, not in general. We can only do it for a class of human semantics that C++ folks call "Zero-Cost Abstractions", the set of abstractions that can be completely erased without a trace by the time you get to the executable.

But otherwise, there is a fundamental cost to making code more readable by humans: making it less readable by the machines that will execute it. This is a reflection of the fundamental alienness of computers, what they find quite easy you find quite hard and vice verca. Optimizing for huamans means generality and ruthless hiding of details, optimizing for machines is all about special cases and ruthless exploitation of assumptions.

(Incidentally, C is not all what it's cracked up to be. Generic containers, off the top of my head, resort to using void* pointers for data and function pointers for operation, which has a runtime cost besides being unsafe and error-prone. Templates in C++ can aggressively inline types and operations for you, on the other hand as if you haven't written generic code at all, no wonder templates is the poster boy for C++'s 0-Cost abstractions. Another example I hear often is how pointer semantics in C and C++ makes it extraordinarily difficult for the compiler to optimize array and memory operations, whereas a language like Fortran make it easier by not having pointers.)

For many things, I have found this easy language is C++.

I use JavaScript and C++ for different things, sometimes in the same day. (And python and PHP and others, but this is not relevant.)

Believe me, JavaScript can be a real head scratcher compared to C++.

And now for the purists: No, I don't use all features of C++, only the minimal necessary ones for the problem I have to solve. This ridiculous idea that you are not using C++ if you are not using every single language feature is what makes programs difficult to write and maintain.

Who says we don't? I think I'm past-due for my regular Ada plug, so uh, here it is.

We can.

https://nim-lang.org/

D as well, though only (like Rust) if you keep the traits and template stuff low.

The nice thing about D for me is that you can generally banish the unreadable metaprogramming code to a library.

Ocaml 5 and Koka (https://koka-lang.github.io/koka/doc/index.html) can get quite close to the speed of C...

Unfortunately, Koka doesn't seem to be ready for general-purpose use…

>Why can't we have a language easy to read and maintain but also have the speed of C?

Swap out { } for Begin End, and make a few other changes, and you've got Pascal. Single pass pascal compilers have been faster (at compiling) that almost anything out there since Turbo Pascal 3.0 for MS-DOS.

Modern versions, such as Free Pascal, Delphi and Lazarus also deal with strings in a manner that totally avoids needing to manually manage memory. The GUI builders are awesome as well.

Transpile to C? Zig or Rust?

Yeah I think Zig in particular is trying to be just exactly a "better C".

I don't know if transpiling will get you there, because for instance if you're transpiling a dynamic language, you're going to have to output C that is essentially emulating all those dynamic language features, so it might be faster than say, the original Python, but it's not going to be as fast as a pure C implementation.

You can't just "transpile to C" to get "C speed". C speed comes from low overhead. Naive transpilations will just include that overhead, like garbage collection or many layers of pointer indirection, but written in C. The unsavory answer is that you must use less abstractions if you want fast code. Compilers just aren't good enough to compile all the abstractions away.

That includes C versus modern CPUs.

The CPU is the CPU regardless of what language you are running on it. C will still give you the best performance on a modern CPU.

If anything, C has an even bigger advantage on modern CPUs because it has easier access to things like vectorize/SIMD intrinsics. It is also easier to tweak your data dependencies to help the branch predictor.

> If anything, C has an even bigger advantage on modern CPUs because it has easier access to things like vectorize/SIMD intrinsics. It is also easier to tweak your data dependencies to help the branch predictor.

Have you seen the ridiculously complex optimizations that C compilers do to maybe turn some shitty for loop into vector instructions? C is terribly bad fit for this use case and hardware tries to get closer to C than the reverse.

C++, Rust but even C# and Java has much better SIMD support than C has.

EDIT: It really doesn’t help C (and some of the listed languages as well) that they are very imperative. SIMD is exactly the place where pureness and some form of FP is much better at allowing these kind of optimizations (a map of a pure function can be “trivially” optimized into vector instructions, while it is really hard to decide whether this for loop is safe to convert, and it is really up to the heuristics of the compiler. A bit of rearrangement can cause a failure to optimize, resulting in a huge drop in performance)

Nope, those are language extensions not defined by ISO C.

Any language can have such intrinsics as extensions, for example D, Rust, C++, Swift, .NET, Java (as preview).

> Transpile to C?

If you transpile something to C it does't mean it will be fast. You can write slow C code (or transpile something to C that will be slow). The compilers are not the issue here.

In fact it might be slower than actually targeting a proper compiler intermediate language.

Julia is that for a lot of academia + mathematics based code.

Zig!

We do. It's called D

Or VLang: https://news.ycombinator.com/item?id=31944777

Ada Programming Language

> Why can't we have a language easy to read and maintain but also have the speed of C?

Fortran is fine. Also lua (using the luajit interpreter you get really close to C speed) and julia (except for the atrocious startup time).

Reply on news.ycombinator.com