10 ms·

I always thought of Go as low level and Rust as high level. Go has a lot of verbosity as a "better C" with GC. Rust has low level control but many functional in

I always thought of Go as low level and Rust as high level. Go has a lot of verbosity as a "better C" with GC. Rust has low level control but many functional inspired abstractions. Just try writing iteration or error handling in either one to see.

steveklabnik 10mo ago
Rue author here, yeah I'm not the hugest fan of "low level vs high level" framing myself, because there are multiple valid ways of interpreting it. As you yourself demonstrate! As some of the larger design decisions come into place, I'll find a better way of describing it. Mostly, I am not really trying to compete with C/C++/Rust on speed, but I'm not going to add a GC either. So I'm somewhere in there.
- written-beyond 10mo ago
  How very so humble of you to not mention being one of the primary authors behind TRPL book. Steve you're a gem to the world of computing. Always considered you the J. Kenji of the Rust world. Seems like a great project let's see where it goes!
  - steveklabnik 10mo ago
    That is a very kind thing to say, I admire him quite a bit. Thank you!
- manaskarekar 10mo ago
  Since it's framed as 'in between' Rust and Go, is it trying to target an intersection of both languages' use-cases?
  - steveklabnik 10mo ago
    I don't think you'd want to write an operating system in Rue. I may not include an "unsafe" concept, and will probably require a runtime. So that's some areas where Rust will make more sense. As for Go... I dunno. Go has a strong vision around concurrency, and I just don't have one yet. We'll see.
    - ChrisSD 10mo ago
      Do you have plans for handling C FFI without "unsafe"? Will it require some sort of extension module written in C/C++/Rust?
      - steveklabnik 10mo ago
        No direct plans. For the immediate future, only the runtime is allowed to call into C. If this ever becomes a production thing, then I can worry about FFI, and I'll probably just follow what managed languages do here.
        tracker1 10mo ago
        FWIW, I really like the way C# has approached this need... most usage is exposed via attribute declaration/declaration DllImport for P/Invoke. Contrasted with say JNI in Java or even the Go syntax. The only thing that might be a significant improvement would be an array/vector of lookup names for the library on the system given how specific versions are often tagged in Linux vs Windows.
- killingtime74 10mo ago
  Wow didn't realise it was you who was the author. I learnt a lot about Rust from your writings.
  - steveklabnik 10mo ago
    I'm glad to have helped you :)
- chrysoprace 10mo ago
  Do you think you'll explore some of the same problem spaces as Rust? Lifetimes and async are both big pain points of Rust for me, so it'd be interesting to see a fresh approach to these problems. I couldn't see how long-running memory is handled, is it handled similar to Rust?
  - steveklabnik 10mo ago
    I'm going to try and avoid lifetimes entirely. They're great in Rust! But I'm going to a higher level spot. I'm totally unsure about async. Right now there's no heap memory at all. I'll get there :) Sorta similar to Rust/Swift/Hylo... we'll see!
    - lamontcg 10mo ago
      So if you don't have a garbage collector, and you don't have manual memory management, and you don't have lifetimes... What do you have?
      - steveklabnik 10mo ago
        The plan is something like mutable value semantics and linear types. I'm figuring it out :)
- AdieuToLogic 10mo ago
  > Mostly, I am not really trying to compete with C/C++/Rust on speed, but I'm not going to add a GC either. So I'm somewhere in there. Out of curiosity, how would you compare the goals of Rue with something like D[0] or one of the ML-based languages such as OCaml[1]? EDIT: This is a genuine language design question regarding an imperative/OOP or declarative/FP focus and is relevant to understanding the memory management philosophy expressed[2]: No garbage collector, no manual memory management. A work in progress, though. 0 - https://dlang.org/ https://dlang.org/ 1 - https://ocaml.org/ https://ocaml.org/ 2 - https://rue-lang.dev/ https://rue-lang.dev/
  - steveklabnik 10mo ago
    Closer to an OCaml than a D, in terms of what I see as an influence. But it's likely to be more imperative/FP than OOP/declarative, even though I know those axes are usually considered to be the way you put them than the way I put them.
    - AdieuToLogic 10mo ago
      > But it's likely to be more imperative/FP than OOP/declarative, even though I know those axes are usually considered to be the way you put them than the way I put them. Fascinating. I look forward to seeing where you go with Rue over time.
- ksec 10mo ago
  Is this a simplified / distilled version of Rust ? Or Subset of Rust with some changes ?
  - steveklabnik 10mo ago
    Some of it is like that, but some of it is going to be from other stuff too. I'm figuring it out :)
  - rob74 10mo ago
    Simplified as in easier to use, or simplified as in less language features? I'm all for the former, while the latter is also worth considering (but hard to get right, as all the people who consider Go a "primitive" language show)...
- a96 10mo ago
  Since that seems to be the (frankly bs) slogan that almost entirely makes up the languages lading page, I expect it's really going to hurt the language and/or make it all about useless posturing. That said, I'm an embedded dev, so the "level" idea is very tangible. And Rust is also very exciting for that reason and Rue might be as well. I should have a look, though it might not be on the way to be targeting bare metal soon. :)
  - steveklabnik 10mo ago
    I don't mind if a sentence I threw up for a side project "hurts the language" at this stage, this is a project primarily for me. You should use Rust for embedded, I doubt Rue will ever be good for it.
- pron 10mo ago
  > because there are multiple valid ways of interpreting i There are quantitative ways of describing it, at least on a relative level. "High abstraction" means that interfaces have more possible valid implementations (whether or not the constraints are formally described in the language, or informally in the documentation) than "low abstraction": https://news.ycombinator.com/item?id=46354267 https://news.ycombinator.com/item?id=46354267
- dxxvi 10mo ago
  You couldn't get the rue-lang.org domain? There are rust-lang.org, scala-lang.org, so rue-lang.org sounds better than .dev. I'd love to see how Rue solves/avoids the problems that Rust's borrow checker tries to solves. You should put it on the 1st page, I think.
  - steveklabnik 10mo ago
    Already taken. I'll put more about that there once it's implemented :)
batisteo 10mo ago
C was designed as a high level language and stayed so for decades
- AdieuToLogic 10mo ago
  > C was designed as a high level language and stayed so for decades C was designed as a "high level language" relative to the assembly languages available at the time and effectively became a portable version of same in short order. This is quite different to other "high level languages" at the time, such as FORTRAN, COBOL, LISP, etc.
  - pjmlp 10mo ago
    When C was invented, K&R C, it was hardly lower level than other systems programming languages that predated it, since JOVIAL in 1958. It didn't not even had compiler intrisics, a concept introduced by ESPOL in 1961, allowing to program Burroughs systems without using an external Assembler. K&R C was high level enough that many of the CPU features people think about nowadays when using compiler extensions, as they are not present in the ISO C standard, had to be written as external Assembly code, the support for inline Assembly came later.
    - AdieuToLogic 10mo ago
      I think we are largely saying the same thing, as described in the introduction of the K&R C book: C is a relatively "low level" language. This characterization is not pejorative; it simply means that C deals with the same sort of objects that most computers do, namely characters, numbers, and addresses.[0] 0 - https://dn710204.ca.archive.org/0/items/the-c-programming-language-second-edition-first-190-pages/The%20C%20Programming%20Language%20%28Second%20Edition%29%20-%20First%20190-pages_text.pdf https://dn710204.ca.archive.org/0/items/the-c-programming-la...
gpm 10mo ago
I wonder if it's useful to think of this as go is low type-system-complexity and rust is high type-system-complexity. Where type system complexity entails a tradeoff between the complexity of the language and how powerful the language is in allowing you to define abstractions. As an independent axis from close to the underlying machine/far away from the underlying machine (whether virtual like wasm or real like a systemv x86_64 abi), which describes how closely the language lets you interact with the environment it runs in/how much it abstracts that environment away in order to provide abstractions. Rust lives in high type system complexity and close to the underlying machine environment. Go is low type system complexity and (relative to rust) far from the underlying machine.
- steveklabnik 10mo ago
  I think this is insightful! I'm going to ponder it, thank you. I think it may gesture towards what I'm trying to get at.
- pron 10mo ago
  > Where type system complexity entails a tradeoff between the complexity of the language and how powerful the language is in allowing you to define abstractions. I don't think that's right. The level of abstraction is the number of implementations that are accepted for a particular interface (which includes not only the contract of the interface expressed in the type system, but also informally in the documentation). E.g. "round" is a higher abstraction than "red and round" because the set of round things is larger than the set of red and round things. It is often untyped languages that offer the highest level of abstraction, while a sophisticated type system narrows abstraction (it reduces the number of accepted implementations of an interface). That's not to say that higher abstraction is always better - although it does have practical consequences, explained in the next paragraph - but the word "abstraction" does mean something specific, certainly more specific than "describing things". How the level of abstraction is felt is by considering how many changes to client code (the user of an interface) is required when making a change to the implementation. Languages that are "closer to the underlying machine" - especially as far as memory management goes - generally have lower abstraction than languages that are less explicit about memory management. A local change to how a subroutine manages memory typically requires more changes to the client - i.e. the language offers a lower abstraction - in a language that's "closer to the metal", whether the language has a rich type system like Rust or a simpler type system like C, than a language that is farther away.
josephg 10mo ago
Yep. This was the biggest thing that turned me off Go. I ported the same little program (some text based operational transform code) to a bunch of languages - JS (+ typescript), C, rust, Go, python, etc. Then compared the experience. How were they to use? How long did the programs end up being? How fast did they run? I did C and typescript first. At the time, my C implementation ran about 20x faster than typescript. But the typescript code was only 2/3rds as many lines and much easier to code up. (JS & TS have gotten much faster since then thanks to improvements in V8). Rust was the best of all worlds - the code was small, simple and easy to code up like typescript. And it ran just as fast as C. Go was the worst - it was annoying to program (due to a lack of enums). It was horribly verbose. And it still ran slower than rust and C at runtime. I understand why Go exists. But I can't think of any reason I'd ever use it.
- andrewmcwatters 10mo ago
  There's a lot of ecosystem behind it that makes sense for moving off of Node.js for specific workloads, but isn't as easily done in Rust. So it works for those types of employers and employees who need more performance than Node.js, but can't use C for practical reasons, or can't use Rust because specific libraries don't exist as readily supported by comparison.
- wswin 10mo ago
  Rust gets harder with codebase size, because of borrow checker. Not to mention most of the communication libraries decided to be async only, which adds another layer of complexity.
  - gpm 10mo ago
    I strongly disagree with this take. The borrow checker, and rust in general, keeps reasoning extremely local. It's one of the languages where I've found that difficulty grows the least with codebase size, not the most. The borrow checker does make some tasks more complex, without a doubt, because it makes it difficult to express something that might be natural in other languages (things including self referential data structures, for instance). But the extra complexity is generally well scoped to one small component that runs into a constraint, not to the project at large. You work around the constraint locally, and you end up with a public (to the component) API which is as well defined and as clean (and often better defined and cleaner because rust forces you to do so).
asim 10mo ago
Agree with Go being basically C with string support and garbage collection. Which makes it a good language. I think rust feels more like a c++ replacement. Especially syntactically. But each person will say something different. If people can create new languages and there's a need then they will. Not to say it's a good or bad thing but eventually it would be good to level up properly. Maybe AI does that.
pjmlp 10mo ago
All are high level as long as they don't expose CPU capabilities, even ISO C is high level, unless we count in language extensions that are compiler specific, and any language can have compiler extensions.
- 9rx 10mo ago
  C pointers expose CPU capabilities. You can always emulate functionality on different architectures, though, so where is the practical line even drawn?
  - pjmlp 10mo ago
    C pointers are nothing special, plenty of languages expose pointers, even classical BASIC with PEEK and POKE. The line is blurred, and doesn't help that some folks help spread the urban myth C is special somehow, only because they never bother with either the history of programming language, and specially the history of systems programming outside Bell Labs.
    - 9rx 10mo ago
      They're nothing special, but were designed for a particular CPU and expose the details of that CPU. And since we were talking about C specifically, not a bunch of other random languages that may have did similar things... While most modern CPUs are designed for C and thus share in the same details, if your CPU is of a different design, you have to emulate the behaviour. Which works perfectly fine — but the question remains outstanding: Where does the practical line get drawn? Is 6502 assembler actually a high-level language too? After all, you too can treat it as an abstract machine and emulate its function on any other CPU just the same as you do with C pointers.
stared 10mo ago
I think it is precisely why Rust is gold - you can pick the abstraction level you work at. I used it a lot when simulating quantum physics - on one hand, needed to implement low-level numerical operations with custom data structures (to squeeze as much performance as possible), on the other - be able to write and debug it easily. It is similar to PyTorch (which I also like), where you can add two tensors by hand, or have your whole network as a single nn.Module.
dismalaf 10mo ago
Go has a GC and Rust doesn't. That alone makes Go higher level.
gf000 10mo ago
Low and high level are not well-defined concepts. One, objective definition is simply that everything that is not an assembly is a high-level language - but that is quite a useless def. The other is about how "deeply" you can control the execution, e.g. you have direct control of when and what gets allocated, or some control over vectorization, etc. Here Rust is obviously as low-level as C, if not more so (both have total control over allocations, but still leaves calling conventions and such up to the compiler), while go is significantly higher (the same level as C#, slightly lower than Java - managed language with a GC and value types). The other often mistaken spectrum is expressivity, which is not directly related to low/high levelness. E.g. both Rust and Scala are very expressive languages, but one is low, the other is high level. C and Go both have low expressivity, and one is low the other is high level. This answer is imo a very must have read about the topic of expressivity: https://langdev.stackexchange.com/a/2016 https://langdev.stackexchange.com/a/2016

steveklabnik 10mo ago

Rue author here, yeah I'm not the hugest fan of "low level vs high level" framing myself, because there are multiple valid ways of interpreting it. As you yourself demonstrate! As some of the larger design decisions come into place, I'll find a better way of describing it. Mostly, I am not really trying to compete with C/C++/Rust on speed, but I'm not going to add a GC either. So I'm somewhere in there.

written-beyond 10mo ago
How very so humble of you to not mention being one of the primary authors behind TRPL book. Steve you're a gem to the world of computing. Always considered you the J. Kenji of the Rust world. Seems like a great project let's see where it goes!
- steveklabnik 10mo ago
  That is a very kind thing to say, I admire him quite a bit. Thank you!
manaskarekar 10mo ago
Since it's framed as 'in between' Rust and Go, is it trying to target an intersection of both languages' use-cases?
- steveklabnik 10mo ago
  I don't think you'd want to write an operating system in Rue. I may not include an "unsafe" concept, and will probably require a runtime. So that's some areas where Rust will make more sense. As for Go... I dunno. Go has a strong vision around concurrency, and I just don't have one yet. We'll see.
  - ChrisSD 10mo ago
    Do you have plans for handling C FFI without "unsafe"? Will it require some sort of extension module written in C/C++/Rust?
    - steveklabnik 10mo ago
      No direct plans. For the immediate future, only the runtime is allowed to call into C. If this ever becomes a production thing, then I can worry about FFI, and I'll probably just follow what managed languages do here.
      - tracker1 10mo ago
        FWIW, I really like the way C# has approached this need... most usage is exposed via attribute declaration/declaration DllImport for P/Invoke. Contrasted with say JNI in Java or even the Go syntax. The only thing that might be a significant improvement would be an array/vector of lookup names for the library on the system given how specific versions are often tagged in Linux vs Windows.
killingtime74 10mo ago
Wow didn't realise it was you who was the author. I learnt a lot about Rust from your writings.
- steveklabnik 10mo ago
  I'm glad to have helped you :)
chrysoprace 10mo ago
Do you think you'll explore some of the same problem spaces as Rust? Lifetimes and async are both big pain points of Rust for me, so it'd be interesting to see a fresh approach to these problems. I couldn't see how long-running memory is handled, is it handled similar to Rust?
- steveklabnik 10mo ago
  I'm going to try and avoid lifetimes entirely. They're great in Rust! But I'm going to a higher level spot. I'm totally unsure about async. Right now there's no heap memory at all. I'll get there :) Sorta similar to Rust/Swift/Hylo... we'll see!
  - lamontcg 10mo ago
    So if you don't have a garbage collector, and you don't have manual memory management, and you don't have lifetimes... What do you have?
    - steveklabnik 10mo ago
      The plan is something like mutable value semantics and linear types. I'm figuring it out :)
AdieuToLogic 10mo ago
> Mostly, I am not really trying to compete with C/C++/Rust on speed, but I'm not going to add a GC either. So I'm somewhere in there. Out of curiosity, how would you compare the goals of Rue with something like D[0] or one of the ML-based languages such as OCaml[1]? EDIT: This is a genuine language design question regarding an imperative/OOP or declarative/FP focus and is relevant to understanding the memory management philosophy expressed[2]: No garbage collector, no manual memory management. A work in progress, though. 0 - https://dlang.org/ https://dlang.org/ 1 - https://ocaml.org/ https://ocaml.org/ 2 - https://rue-lang.dev/ https://rue-lang.dev/
- steveklabnik 10mo ago
  Closer to an OCaml than a D, in terms of what I see as an influence. But it's likely to be more imperative/FP than OOP/declarative, even though I know those axes are usually considered to be the way you put them than the way I put them.
  - AdieuToLogic 10mo ago
    > But it's likely to be more imperative/FP than OOP/declarative, even though I know those axes are usually considered to be the way you put them than the way I put them. Fascinating. I look forward to seeing where you go with Rue over time.
ksec 10mo ago
Is this a simplified / distilled version of Rust ? Or Subset of Rust with some changes ?
- steveklabnik 10mo ago
  Some of it is like that, but some of it is going to be from other stuff too. I'm figuring it out :)
- rob74 10mo ago
  Simplified as in easier to use, or simplified as in less language features? I'm all for the former, while the latter is also worth considering (but hard to get right, as all the people who consider Go a "primitive" language show)...
a96 10mo ago
Since that seems to be the (frankly bs) slogan that almost entirely makes up the languages lading page, I expect it's really going to hurt the language and/or make it all about useless posturing. That said, I'm an embedded dev, so the "level" idea is very tangible. And Rust is also very exciting for that reason and Rue might be as well. I should have a look, though it might not be on the way to be targeting bare metal soon. :)
- steveklabnik 10mo ago
  I don't mind if a sentence I threw up for a side project "hurts the language" at this stage, this is a project primarily for me. You should use Rust for embedded, I doubt Rue will ever be good for it.
pron 10mo ago
> because there are multiple valid ways of interpreting i There are quantitative ways of describing it, at least on a relative level. "High abstraction" means that interfaces have more possible valid implementations (whether or not the constraints are formally described in the language, or informally in the documentation) than "low abstraction": https://news.ycombinator.com/item?id=46354267 https://news.ycombinator.com/item?id=46354267
dxxvi 10mo ago
You couldn't get the rue-lang.org domain? There are rust-lang.org, scala-lang.org, so rue-lang.org sounds better than .dev. I'd love to see how Rue solves/avoids the problems that Rust's borrow checker tries to solves. You should put it on the 1st page, I think.
- steveklabnik 10mo ago
  Already taken. I'll put more about that there once it's implemented :)

batisteo 10mo ago

C was designed as a high level language and stayed so for decades

AdieuToLogic 10mo ago
> C was designed as a high level language and stayed so for decades C was designed as a "high level language" relative to the assembly languages available at the time and effectively became a portable version of same in short order. This is quite different to other "high level languages" at the time, such as FORTRAN, COBOL, LISP, etc.
- pjmlp 10mo ago
  When C was invented, K&R C, it was hardly lower level than other systems programming languages that predated it, since JOVIAL in 1958. It didn't not even had compiler intrisics, a concept introduced by ESPOL in 1961, allowing to program Burroughs systems without using an external Assembler. K&R C was high level enough that many of the CPU features people think about nowadays when using compiler extensions, as they are not present in the ISO C standard, had to be written as external Assembly code, the support for inline Assembly came later.
  - AdieuToLogic 10mo ago
    I think we are largely saying the same thing, as described in the introduction of the K&R C book: C is a relatively "low level" language. This characterization is not pejorative; it simply means that C deals with the same sort of objects that most computers do, namely characters, numbers, and addresses.[0] 0 - https://dn710204.ca.archive.org/0/items/the-c-programming-language-second-edition-first-190-pages/The%20C%20Programming%20Language%20%28Second%20Edition%29%20-%20First%20190-pages_text.pdf https://dn710204.ca.archive.org/0/items/the-c-programming-la...

gpm 10mo ago

I wonder if it's useful to think of this as go is low type-system-complexity and rust is high type-system-complexity. Where type system complexity entails a tradeoff between the complexity of the language and how powerful the language is in allowing you to define abstractions. As an independent axis from close to the underlying machine/far away from the underlying machine (whether virtual like wasm or real like a systemv x86_64 abi), which describes how closely the language lets you interact with the environment it runs in/how much it abstracts that environment away in order to provide abstractions. Rust lives in high type system complexity and close to the underlying machine environment. Go is low type system complexity and (relative to rust) far from the underlying machine.

steveklabnik 10mo ago
I think this is insightful! I'm going to ponder it, thank you. I think it may gesture towards what I'm trying to get at.
pron 10mo ago
> Where type system complexity entails a tradeoff between the complexity of the language and how powerful the language is in allowing you to define abstractions. I don't think that's right. The level of abstraction is the number of implementations that are accepted for a particular interface (which includes not only the contract of the interface expressed in the type system, but also informally in the documentation). E.g. "round" is a higher abstraction than "red and round" because the set of round things is larger than the set of red and round things. It is often untyped languages that offer the highest level of abstraction, while a sophisticated type system narrows abstraction (it reduces the number of accepted implementations of an interface). That's not to say that higher abstraction is always better - although it does have practical consequences, explained in the next paragraph - but the word "abstraction" does mean something specific, certainly more specific than "describing things". How the level of abstraction is felt is by considering how many changes to client code (the user of an interface) is required when making a change to the implementation. Languages that are "closer to the underlying machine" - especially as far as memory management goes - generally have lower abstraction than languages that are less explicit about memory management. A local change to how a subroutine manages memory typically requires more changes to the client - i.e. the language offers a lower abstraction - in a language that's "closer to the metal", whether the language has a rich type system like Rust or a simpler type system like C, than a language that is farther away.

josephg 10mo ago

Yep. This was the biggest thing that turned me off Go. I ported the same little program (some text based operational transform code) to a bunch of languages - JS (+ typescript), C, rust, Go, python, etc. Then compared the experience. How were they to use? How long did the programs end up being? How fast did they run? I did C and typescript first. At the time, my C implementation ran about 20x faster than typescript. But the typescript code was only 2/3rds as many lines and much easier to code up. (JS & TS have gotten much faster since then thanks to improvements in V8). Rust was the best of all worlds - the code was small, simple and easy to code up like typescript. And it ran just as fast as C. Go was the worst - it was annoying to program (due to a lack of enums). It was horribly verbose. And it still ran slower than rust and C at runtime. I understand why Go exists. But I can't think of any reason I'd ever use it.

andrewmcwatters 10mo ago
There's a lot of ecosystem behind it that makes sense for moving off of Node.js for specific workloads, but isn't as easily done in Rust. So it works for those types of employers and employees who need more performance than Node.js, but can't use C for practical reasons, or can't use Rust because specific libraries don't exist as readily supported by comparison.
wswin 10mo ago
Rust gets harder with codebase size, because of borrow checker. Not to mention most of the communication libraries decided to be async only, which adds another layer of complexity.
- gpm 10mo ago
  I strongly disagree with this take. The borrow checker, and rust in general, keeps reasoning extremely local. It's one of the languages where I've found that difficulty grows the least with codebase size, not the most. The borrow checker does make some tasks more complex, without a doubt, because it makes it difficult to express something that might be natural in other languages (things including self referential data structures, for instance). But the extra complexity is generally well scoped to one small component that runs into a constraint, not to the project at large. You work around the constraint locally, and you end up with a public (to the component) API which is as well defined and as clean (and often better defined and cleaner because rust forces you to do so).

asim 10mo ago

Agree with Go being basically C with string support and garbage collection. Which makes it a good language. I think rust feels more like a c++ replacement. Especially syntactically. But each person will say something different. If people can create new languages and there's a need then they will. Not to say it's a good or bad thing but eventually it would be good to level up properly. Maybe AI does that.

pjmlp 10mo ago

All are high level as long as they don't expose CPU capabilities, even ISO C is high level, unless we count in language extensions that are compiler specific, and any language can have compiler extensions.

9rx 10mo ago
C pointers expose CPU capabilities. You can always emulate functionality on different architectures, though, so where is the practical line even drawn?
- pjmlp 10mo ago
  C pointers are nothing special, plenty of languages expose pointers, even classical BASIC with PEEK and POKE. The line is blurred, and doesn't help that some folks help spread the urban myth C is special somehow, only because they never bother with either the history of programming language, and specially the history of systems programming outside Bell Labs.
  - 9rx 10mo ago
    They're nothing special, but were designed for a particular CPU and expose the details of that CPU. And since we were talking about C specifically, not a bunch of other random languages that may have did similar things... While most modern CPUs are designed for C and thus share in the same details, if your CPU is of a different design, you have to emulate the behaviour. Which works perfectly fine — but the question remains outstanding: Where does the practical line get drawn? Is 6502 assembler actually a high-level language too? After all, you too can treat it as an abstract machine and emulate its function on any other CPU just the same as you do with C pointers.

stared 10mo ago

I think it is precisely why Rust is gold - you can pick the abstraction level you work at. I used it a lot when simulating quantum physics - on one hand, needed to implement low-level numerical operations with custom data structures (to squeeze as much performance as possible), on the other - be able to write and debug it easily. It is similar to PyTorch (which I also like), where you can add two tensors by hand, or have your whole network as a single nn.Module.

dismalaf 10mo ago

Go has a GC and Rust doesn't. That alone makes Go higher level.

gf000 10mo ago

Low and high level are not well-defined concepts. One, objective definition is simply that everything that is not an assembly is a high-level language - but that is quite a useless def. The other is about how "deeply" you can control the execution, e.g. you have direct control of when and what gets allocated, or some control over vectorization, etc. Here Rust is obviously as low-level as C, if not more so (both have total control over allocations, but still leaves calling conventions and such up to the compiler), while go is significantly higher (the same level as C#, slightly lower than Java - managed language with a GC and value types). The other often mistaken spectrum is expressivity, which is not directly related to low/high levelness. E.g. both Rust and Scala are very expressive languages, but one is low, the other is high level. C and Go both have low expressivity, and one is low the other is high level. This answer is imo a very must have read about the topic of expressivity: https://langdev.stackexchange.com/a/2016 https://langdev.stackexchange.com/a/2016