Get the top HN stories in your inbox every day.
flohofwoe
A small but (IMHO) very neat detail is the Pascal-style syntax for defining variables (without requiring a separate 'var' or 'let' keyword):
// inferred type:
a := 23
// explicitly typed, the type is squeezed between the : and =
a : u32 = 23
a :: 23
my_func :: proc(...)
a : u32 : 23brabel
So, the pattern is:
<const_name> : [type] : <value>
<var_name> : [type] = <value>
That's why `a :: 32` declares a constant, but `a := 32` declares a variable...
This is pretty neat, actually.
mananaysiempre
This pun originates from Limbo, I think. Go inherits the colon-equals for the inferred-type definition, but not the colon for type ascription, yet another way in which it could have been beautiful but isn’t.
gingerBill
It's slightly older than Limbo, and comes from Newsqueak. The difference is that Newsqueak used keywords for the other non-variable declarations. `x: int = 123`, `const X: int = 123`, `type My_Int: int`, etc.
ceronman
Odin sounds like a nice improvement over C, however this caught my attention:
> If your “dread” of C comes from fear of memory management, then Odin is probably not for you, and dare I say, maybe systems programming is not for you.
I have to say that my dread of C definitely comes manual memory management. The awkward syntax and compilation model I can tolerate. But having your program expose critical security vulnerabilities because you forgot a weird edge case while managing a pointer is really worrying. For simple programs is not that complicated, but for complex multi threaded ones it becomes really hard. And the fact that event the most expert programmers make these mistakes, leaves me not much hope.
So perhaps systems programming is not for me? But what exactly is systems programming? Is it developing OS kernels, writing drivers and embedded microcontroller systems? Or is it more.
I'm not very interested in writing any of those. But I do want to write programs that are fast and run as fast as C or C++, and I want a language which allows good control of resources and has minimal overhead. Sometimes these programs are multi-threaded and quite complex, so I want memory and type safety and I want tools to crate abstractions to tame complexity a little bit. Is all this out of the systems programming definition?
sirwhinesalot
Rust sounds like what you want, though be prepared to deal with near C++ levels of complexity at times (lots of Rust code is too macro happy for my tastes).
That said, the way to deal with memory management in C is to... not do much of it. I know that sounds like a cop-out but the patterns you're supposed to use in languages like Zig and Odin are the same ones you'd use in C to keep your mind sane.
Do not do Reference Counting or Single Owner + Borrowing (RAII), it'll drive you insane without the automation languages like Swift and Rust or C++ give you.
Instead, the way you're supposed to do things, are big "manager objects". Only these manager objects are ever explicitly allocated and freed, everything stored within them is managed by them and they expose only safe handles to the outside world (e.g. generational handles).
Most of the time these manager objects will store some dynamic arrays, hash maps or pools within them that get freed when they are also freed. Note that unlike RAII there is no real "nesting". The managers are responsible for the lifetimes of their whole "object tree".
Any temporary data should be allocated using a temporary allocator (like an Arena allocator) which gets freed at the appropriate place for the application (end of a frame in a game, or end of a request in a web server). Never store pointers to something within the temporary allocator in "long lived" data structures inside the manager object.
Follow these rules and things get manageable, Zig and Odin have lots of facilities in their standard libraries to make this easier, in C you're mostly on your own but there are some libraries you could use like the Apache Portable Runtime.
dqpb
I’ll admit, the fact that Hello World requires a macro, dissuaded me from learning Rust for years.
WaffleIronMaker
Technically, you don't need a macro at all:
use std::io::Write;
fn main() {
std::io::stdout().write(b"Hello, world!\n").unwrap();
}
println!("x is: {}", x);
These reasons tie directly into Rust's philosophy of making it easy to write reliable, performant code.
Cyberdog
You’re using the past tense. Did your mind change?
sanderjd
Yeah this kind of framing always rubs me the wrong way. I don't "dread" manual memory management. Indeed, from a personal standpoint I really like thinking about stuff like that while I'm programming. It's part of the fun puzzle aspect that got me into all this. But as a professional, I know that there is heaps of evidence over many decades that it is unwise for me to indulge this fancy, when working on real systems that real people use and which may be exposed to the internet. I consider it a bummer, but I'm very persuaded that this is unwise for pretty much all of the software I work on.
abainbridge
You can have safe manual memory management. The main cases of bugs are:
1. Null pointer deref. Can be fixed by having optional types and requiring that possibly null pointers have to be wrapped in them.
2. Out of bounds references. Can be fixed by making the type system track how big all objects are, and having the compiler insert bounds checking.
3. Use after free. Can be fixed by the free function zero'ing heap objects smaller than a page (eg 4KB), and unmapping larger ones so that future accesses are a seg fault. The heap also needs to not create new objects at the same address as deleted ones, but we have 64-bit address spaces, so maybe that's fine.
These all have costs, but so do all solutions to these problems.
I can't think of any reasons that a language with manual memory management has to be less safe than one with a Garbage Collector / ARC.
gingerBill
You are correct and Odin supports all of this.
`Maybe(^T)` exists in Odin.
Bounds checking is on by default for all array-like access. Odin has fixed-length arrays, slices, dynamic arrays, maps, and #soa arrays, all of which support bounds checking. Odin does not have pointer arithmetic nor implicit array-to-pointer demotion which is pretty much removes most of the unsafety that languages like C have.
Odin also has built-in support for custom allocators which allows you do a lot more with extra safety features too beyond the default allocator. Use-after-free is usually also a symptom of an underlying value responsibility and lifetime problem rather than a problem in itself, of which is fundamentally an architectural issue. Ownership semantics in a language in Rust does deal with this issue BUT it does come at a huge cost in terms of architecting the code itself to accommodate this specific way of programming.
There is a common assumption amongst many of the comments that if you have manual memory management, you are defaulting to memory unsafety. This is untrue and memory management and memory safety are kind of unrelated in the grand scheme of things. You could have C with GC/ARC and still have all of its memory unsafety semantics.
efficax
the last thing is safe concurrency. this is the greatest achievement of the rust borrower checker imo. the ownership model means data races are detected at compile time, eliminating a huge class of concurrent programming bugs without forcing a message passing architecture. deadlocks are still possible if you have two or more mutexes but that’s a much harder problem
sanderjd
By "manual memory management", I think of explicitly allocating and freeing memory. Assuming you're thinking of the same thing, are you suggesting that the compiler (or other static analysis) could catch all of the issues you listed? If so, the natural question is, why is it necessary to manually insert the allocations and frees, if the compiler knows where they are supposed to go?
This path leads you to something like Rust, which is safe without garbage collection or ARC, but I also wouldn't call it "manual memory management". The trade off they took for this is complexity in the language.
hsn915
If you had this belief say, 10 years ago, and because of it you decided to write your serious application in say, Java, you would have been in for a huge unexpected surprise last year when the now infamous log4j vulnerability was made public.
See, having memory safety did not prevent the language from causing arbitrary code execution vulnerabilities. Having the log4j project be open source and popular did not prevent that either (so much for the "enough eye balls" theory).
Going back to Odin, when I think memory safety is not as big a concern as people make it out to be:
Your only source of concern is C.
This would be like judging SQL statements as fundamentally unsafe because websites written in PHP tended to (specially in the early 2000) be written in a very unsafe manner where user input was put directly into SQL strings.
The lesson that people took is not to throw SQL out the window, but to properly sanitize user input before passing to the queries, and to never use plain string concatenation when doing that.
So for manual memory management, the lesson to take from the vulnerabilities that C has caused is not that manual memory mangement is bad. It's that you need some facilities in the language to minimize the chance of them occurring by several orders of magnitude.
Odin does this by providing the slice type (and string type) that have their length known and providing several custom allocators out of the box.
The cool thing about the slice type is not just that the length is known: the language provides facilities for iterating over the slice that automatically never goes out of bound:
for item, index in slice {
// do something
}
These features make the "fear" of unsafe memory access largely unwarranted anymore.
What remains is a matter of what attracts you to programming: are you interested in having explicit control over a system to make it do what you want, or are you more interested in expressing some abstract ideas in an abstract mathematical virtual machine? If the latter, you might find Haskell or Lisp more appealing.
pjmlp
This is the usual speach against memory safe languages adoption, while ignoring the nice security equation,
Σ exploits = Σ memory_corruption + Σ logic_errors
sanderjd
Highlighting a different systemic problem is not at all an argument against avoiding this problem. Indeed, if memory safety were the only problem to worry about, then I'd be less worried about it, because we could spend more time on it. But it isn't, there are all sorts of other things to worry about, simultaneously.
> This would be like judging SQL statements as fundamentally unsafe because websites written in PHP tended to (specially in the early 2000) be written in a very unsafe manner where user input was put directly into SQL strings.
This is indeed a good example, but supports my argument rather than yours. If we had devised ways to make it impossible (or incredibly hard and weird) to introduce sql injection vulnerabilities at the language level, then that would be excellent. One less thing to worry about!
I don't have a unique grudge against memory safety issues. It's just one type of issue that we've spent a lot of time devising solutions to that don't just boil down to "be very careful" and I'm generally supportive of any solution to any problem like that, if the tradeoffs are acceptable.
But I agree with you that it's a great thing to have language and library support that make memory safety issues significantly less common and problematic (to be clear, I only just heard of Odin from this article, but I think it looks pretty awesome on initial glance), and that that gets to the level of solution that we have for sql injection in practice. I think there are somewhat better alternative solutions available in the case of memory safety, but they have different tradeoffs.
> What remains is a matter of what attracts you to programming: are you interested in having explicit control over a system to make it do what you want, or are you more interested in expressing some abstract ideas in an abstract mathematical virtual machine?
I'm mostly interested in the first thing, but I think these are both false choices. There is a language that provides that explicit control with more memory safety (rust) with a different trade off (language complexity), and most other languages are memory safe without being focused on expressing abstract ideas in an abstract mathematical virtual machine (go, java, python, etc. etc.).
kretaceous
Seems like you need Go then? You mention you want memory management, type safety and proper abstractions, hence the suggestion.
Of course, you also mentioned C's syntax as awkward for you, so you might feel the same with Go's syntax.
xyzzy4747
Go is not a fast language compared to C/C++/Rust. It’s more in line with Java as it’s also garbage collected.
Tozen
Go, despite using GC, is still a compiled language. From what I've seen (including various test results), Go is usually faster than Java.
There is also the issue of, what is fast enough? A lot of times, people don't really have the speed requirements they say or think they do. To include the code they have written, could be better optimized. It's often better to be more specific about what the requirements are, before making blanket statements about a language not being fast enough. Clearly, many people are fine with how fast Go is.
kretaceous
That's fair. Go is not as fast and cannot manage resources as well as the languages you mentioned.
BaculumMeumEst
You state that as a blank and white fact, but there's nuance.
https://github.com/lotabout/skim/issues/317#issuecomment-652...
hsn915
The wikipedia definition of systems programming seems to exclude it
IshKebab
I'm not sure what you mean by "it" but nothing in that page precludes languages with runtimes from writing system software. I'd say Go can definitely claim to be a systems language.
xyzzy4747
I think Rust is what you need. It basically won’t compile if your code would have runtime errors or memory leaks, except for cases you need to explicitly handle. The linters in VSCode also make it pretty practical to use. It’s been a joy to program in since I started about a month ago.
proto_lambda
> It basically won’t compile if your code would have runtime errors or memory leaks
While Rust does move a lot of errors from runtime to compile time, there are still a lot of ways to create runtime errors (which must obviously the case if your program handles any input at all).
Rust also does not stop you from creating memory leaks; there's even the `Box::leak()` method[1] that allows you to simply leak a heap allocation.
[1]: https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...
xyzzy4747
The difference is you need to explicitly handle cases that would cause runtime errors where you have to use .unwrap() or match selectors, which makes it safer in general. Since the values are wrapped in Result or Option enums. Code that doesn’t create these types isn’t possible to have runtime errors which reduces cognitive burden when coding.
And yes you can write non-idiomatic Rust that lets you leak memory but it doesn’t happen by accident like in C/C++.
dxuh
I think Odin just doesn't do enough. The improvements over C are there, but imho too small to justify/motivate a large-scale change.
And personally I think (!) there is no reason to introduce a new programming language without RAII these days. If you don't solve memory management any more than C did (not), then you are ignoring the biggest problem that needs solving and every replacement that does address this problem looks more attractive.
gingerBill
And for you, you clearly don't need manual memory management nor high control over memory, memory layout, and memory access. And that's absolutely fine, but don't criticize something which other people REQUIRE and DESIRE. You cannot "solve memory management" because there isn't just "one problem".
As for RAII, the article itself showcases some of the alternatives Odin has with the `defer` statement and `deferred_*` attributes. So Odin can have many of the aspects of RAII without tying it directly to a data-type/struct/class, which itself as many costs and trade-offs. RAII has loads of problems to it and many other things which are required to solve those problems.
This language is just not for you, and that is absolutely fine! But don't proclaim that it's "ignoring the biggest problem that needs solving" when you are assuming everyone has the same needs, requires, and desires as yourself.
n.b. I am the creator of the Odin programming language; go use a language that will help you solve your problems with your requirements.
avgcorrection
Quite the outlashing.
One can use both default RAII in a programming language as well as opt-in unsafe memory management. So you are clearly wrong in your assumptions about what the OP must clearly not require/want.
gingerBill
Still no. Many problems require manual memory management of which custom allocators aid a lot with. Odin has extensive support for custom allocators and many other things.
RAII may not even make sense within the type system of a language too. Languages with RAII (C++, D, Ada, Rust (through Drop), and Vala) all have higher level constructs such as methods, and many have automatic memory management too (Rust's is automatic but at compile time).
First let's take C++ as an example of a RAII language, RAII has numerous flaws to it:
* In practice (but not necessarily) couples allocation/initialization together meaning that allocations are rarely bulked together and are scope-governed (which can be very poor with performance). (And I know placement `new` exists, but that isn't implicit RAII any more and doesn't solve any of the other problems)
* C++ originally only had copy constructors which usually involved loads of implicit allocations everywhere. This lead to copy-elision optimizations and the introduction of move/ownership semantics as a way to minimize these issues.
* RAII is very implicit to the reader that it is even happening, meaning you cannot just read the code and know what is happening.
* Ctors and dtors usually have to assume to never fail, or require exceptions to handle the failure cases. And not everyone wants, or can even have, software exceptions.
In sum, adding RAII is not a minor thing and to make it even useful without too many flaws requires loads of extra things on top. It's not a simple construct.
I also never said anything about memory safety in my comment. You can have memory safety and manual memory management. The question is what level of safety and in what form. Odin has pretty much all the general memory safety features (bounds checking, Maybe types, distinct types, no pointer arithmetic, default to slices, virtual memory protections, and many more). What Odin does not offer is ownership semantics and lifetime semantics, which is an entire discussion itself which I won't talk about in this already long comment.
dxuh
My point was that I don't see much of a point in yet another language that is C with an extra 10%. There is another one like that almost every week.
Plenty of applications that require manual memory management have been written in C++ or Rust, which do provide RAII. If you know that manual memory management is required for some applications, you also know it's not 100% of the code that needs it.
gingerBill
Do you honestly think Odin is "C with an extra 10%"? Or any of the decent alternatives that are available (e.g. Zig, Jai, etc)? Because if you really think that is the case, you know nothing about these languages nor have ever used them. All of these languages provide a hell of a lot more than "10%".
As for RAII, I do explain in another comments (https://news.ycombinator.com/item?id=32629951 & https://news.ycombinator.com/item?id=32631462) why RAII has alternatives and not necessary for every language. If you truly believe that RAII is necessary for you, then use a language that has it (e.g. C++, Rust, D).
mplewis
But safe memory management is the biggest problem that needs solving. It’s empirically impossible for humans to write secure, complex programs while managing memory by hand.
I agree with OP, that Odin doesn’t go far enough toward safety in this regard. We do all require and desire security.
gingerBill
What it is interesting is that the comment never mentions memory safety, only memory management; you just added memory safety into the discuss.
Memory safety and memory management are not equivalent concepts. As I state in another reply (https://news.ycombinator.com/item?id=32629951), you have memory safety and manual memory management. And Odin offers numerous memory safety features as well as being designed around the power of custom allocators.
samatman
I don't think any feature should be a mandatory part of a programming language, provided its reasons for not including it make sense. I'm fuzzy on Odin, if you showed me some Odin and some Hare I bet I couldn't tell them apart, but it kinda looks like a nice C with syntax inspiration from Go and (hence) Pascal.
A language like that, as long as the object code is correct, then hey, it's there for people who want it.
I think Zig, which I understand better but don't use, has a good reason for not building in RAII. Zig has a "no allocation without an allocator" rule, and what's easiest to describe as native valgrind. It also has comptime, and RAII loses some conceptual simplicity when you start doing transformations between what-you-see and what-you-get.
I think it's worth continuing to explore whether that's a sufficient approach to memory safety, rather than doing something which has already been done, prematurely. I happen to think it's a promising approach, favoring clarity and simplicity.
We'll see. Zig can always add RAII later, and so can Odin. But at most once each, so it pays not to be hasty.
gingerBill
Regarding Odin and Hare, I'd argue most people would easily be able to tell them apart from the syntax alone because the declaration syntaxes are quite different. And most people judge a syntax pretty much solely by the declaration syntax itself.
Regarding RAII, I explain in another comment (https://news.ycombinator.com/item?id=32629951) the issues with RAII and what it requires to be useful. Odin has the similar rule of "no allocation without an allocator" but has the implicit `context` system which passes the current context's allocators around. Odin also has core library support for valgrind, callgrind, memcheck, and soon helgrind.
Odin has features (which this article does showcase) which are akin to RAII but are not attached to the type system. And as I explained in the previous comment, RAII wouldn't even make much sense in Odin (or Zig for that matter) and would probably never a good idea to add it later. There are better alternatives to RAII for languages such as Odin and Zig.
samatman
Hi Bill, wasn't intended as a criticism of either, or as an observation about the syntax choices, but rather as a way of saying how familiar I am with both: I could say some things about them which are accurate, but not tell code samples apart.
RAII isn't something I happen to be looking for in a language, it kind of falls between Rust and your work in a way that I don't have a use for.
It's an interesting domain, isn't it? You'll always have people reacting from the hip to the problems C has given us, but they'll be back a couple hours later to talk about the wonders of SQLite.
SQLite got there by being careful and building tools to keep them out of trouble. I see an important role for languages which build those tools in, but don't try to replace a manual transmission with an automatic.
Kukumber
How do you write your garbage collectors or RC without precise manual memory management?
How do you render billions of vertices and maintain a gameplay loop under 8ms for AAA games without precise manual memory/layout management?
Not everyone is writing websites in javascript
YuukiRey
I guess they are referring to something like Rust which manages to "solve memory management" while still letting you write high performance code.
pjmlp
Here, a GC implemented in Oberon, a GC enabled systems programming language,
https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...
For something more modern in D, also a GC enabled systems programming language,
forgotpwd16
D is GC by default (and currently required for larger parts of stdlib) but also allows disabling GC and doing manual memory management.
dxuh
RAII is often optional automatic memory management, like in C++ or Rust. Both of these languages are used for AAA games and rarely used for websites. My point was that if you don't go as far as those two, there is just not much of a point to not using C instead.
Kukumber
Rust is not used in the AAA industry, it was advertised by a company (Embark), but they ended up using Unreal Engine 5 for both of their new upcoming games
godratio
NOT TRUE you would of course choose Odin over C unless you could not for some reason.
Odin is 100x better environment to program in than C. C++ is used for AAA games. Rust is not really used if hardly at all because of the highly competitive and time critical nature and very much the need to change things fast.
stjohnswarts
I agree RAII at a minimum should be available, but why not just use c++ at that point? I'll just go to something like zig or rust that is established and has thousands of libraries available.
gingerBill
I recommend reading my reply to another comment regarding RAII: https://news.ycombinator.com/item?id=32629951
Also the article itself demonstrates different approaches to achieve behaviour similar to RAII through the `defer` statement and `deferred_*` attributes.
jeberle
I'm happy to see Odin chose snake_case instead of camelCase. At one time Zig debated switching to snake case, but that ship has sailed [0], sadly.
It seems like a small bike-shed level comment, but when I consider the code I have left in me, I'd like it to look as nice as possible.
tadfisher
My fingers hate snake_case unless I'm in an IDE with working auto complete, and even then the repeated "shift-minus" when defining variables/functions is just hell on my typing speed. I don't have to remap my keyboard to avoid RSI when using camelCase, and I also don't have to switch keyboard apps on my phone when typing code examples.
Tozen
I totally understand the preference, as using snake_case has grown on me. But, when you jump between many languages (with different case usage), you kind of have to be agnostic about such things.
account-5
I much prefer camelCase over snake_case. No idea why.
ithrow
curious, why do you prefer snake_case to kebab-case?
avgcorrection
I prefer kebab-case but it’s apparently too much to ask for in infix languages because most of them insist on allowing expressions like `a+b-c`.
IshKebab
Never use kebab-case. Not even where you can (e.g. filenames). Sooner or later you're going to want that name as an identifier in a programming language that doesn't support it (approximately all of them), and then you're going to have to come up with annoying rules to convert between them, and make all the code that uses it harder to follow and to grep.
Obvious example is CSS.
MH15
kebab-case conflicts with binary expressions, specifically subtraction? Some parser jujitsu would be required to fix this.
zozbot234
Generally, kebab-case means that operators must be separated by spaces. Languages like FORTH or LISP might not even treat operators as separate from ordinary functions.
torginus
> As someone who is interested in systems programming, and has experience working with Go
I wonder how Go got it's reputation as a systems language. Imo, it occupies the same abstraction level as Java or C#.
hsn915
When Go was first announced ~2009, Rob Pike explicitly framed it as a systems language
https://www.youtube.com/watch?v=rKnDgT73v8s
I would not say it's the same as Java or C#. The crucial difference is that it compiles to a native executable binary file, not something that needs a virtual machine.
sanderjd
It is possible to compile Java and C# binaries. It is true that it is not as common and they were not designed that way, but I think this difference is mostly an implementation detail. I think these are indeed the best comparison languages to Go. They're all mature statically checked languages with good garbage collectors and concurrency features.
Erlangen
I think Rob Pike has changed his idea. I remember watching Youtube video featuring language designers(golang, d and rust), where Rob Pike, Andrei Alexandrescu and Steve Klabnik talked about the stories behind three languages. Rob Pike said something like, "Golang was mistakenly called system language, it should be called server programming language instead".
I tried to find the video on youtube, but to no avail.
undefined
bhedgeoser
C programs are executed inside the C virtual machine.
culi
You mean the C abstract machine?
wizofaus
Can't tell if serious...
randomdata
The simple answer is that it was announced as one.
The more complicated answer is that, traditionally, systems programming languages were those which are not scripting or assembler languages. If you listen to Pike for more than a few seconds you'll soon notice that he's a bit of a language purist, so whatever modern interpretation you might have for a term is unlikely to match what he is communicating.
More specifically, it was announced as a systems programming language designed for things like web servers and systems of that nature, with more control than Java in some areas. Even with conflicting definitions of systems, there should have been no illusions about it being designed to be in roughly the same space as Java with that context. It was very much suggested from the onset that it was meant to compete with Java.
But, ultimately the game of telephone truncated the context that would have helped with finding the right definition of systems and, I expect exacerbate things, there was Rust coming onto the scene juicing the situation with its fans often claiming that "Go isn't a systems language, Rust is!" leaving some revisionism about people believing that Go was a systems language (in the modern sense).
pjmlp
Because languages like Oberon exist, used to write graphical workstations operating systems, and Go has the same set of features as Oberon.
Unless one doesn't consider writing compilers, linkers, GPU debuggers, container management, syscall emulators, unikernels systems programming.
coldtea
>Unless one doesn't consider writing compilers, linkers, GPU debuggers, container management, syscall emulators, unikernels [to be] systems programming.
Since you can write the above with any language, perhaps even Python or Lua if you wanted to, it's not exactly the ability to write the above or the fact of having written the above in a language, that makes a language to be considered a "systems programming language".
In some way, what is called a systems languge it's not a technical capacity thing ("can do X, Y and Z, so it's a systems language").
It's a term applied deliberately, that also includes other aspects.
sophacles
I challenge you to find me two concurring definitions of systems programming that also include enough detail to set clear bounds between what is and isn't systems programming. If you succeed at that, I further challenge you to: find me two concurring definitions of systems programming language that include enough detail to qualify and disqualify languages consistently.
By "enough detail" and "clear bounds" i mean: a group of people independently arriving at the same sets of classification based on your provided definitions.
pjmlp
Sure one can play word games all day long if that is your point.
copx
AFAIK Go was and is primarily used to write back-end server software and this is commonly called "systems programming" (as opposed to application programming) too.
It is kinda confusing that the term is used for that and for low-level embedded/firmware/kernel programming, despite both areas having little in common with each other.
doliveira
> and this is commonly called "systems programming"
Is it, though? My impression it only started with Go calling it that way
undecidabot
System programming languages also used to refer to non-scripting languages. See this paper by John Ousterhout (creator of Tcl) written in 1997: https://users.ece.utexas.edu/~adnan/top/ousterhout-scripting...
ObscureScience
I don't think so. I think it's just the way Rob et al. used the term from their previous experience.
It's not meant to mean operating systems language, nor embedded systems language.
Rather for writing parts of a systems, such as servers. I would say that the definition is not that far away for Java or C#, but the expectation is simply that it would be "lower level" components of a system, including unix like utilities.
wizofaus
Not unreasonable to argue that something like Docker or k8s is more "system software" than an application.
kevinmgranger
I think the definition of "systems" changed over time. It used to mean building the foundations of operating systems, e.g. kernel and basic userland utilities.
Now it means building higher-level userland tools and internet oriented tools. I think the implicit consensus is the lower level stuff is a "solved problem".
agumonkey
I always interpreted go "system" as networked async systems and not electronic chip systems.
rgoulter
I think this makes sense considering that most of the cloud-native software is written with Go. (Docker / Podman, Kubernetes, Helm, Istio, Terraform, etc.)
agumonkey
I don't know if I'm crazy but it matches the definition of a system. Coupling different parts together. These are just high level systems, and unsurprisingly when people see 'system programming language' they want to see high level assembly like C; but it's misplaced reflex in this case.
Shorel
I agree with the others. Go is its own abstraction level.
Not powerful enough to be compared to Java.
Probably closer to Node.js, that's to say, it is like JavaScript in the server. Judging by the developers who use it. Except it is compiled.
noisy_boy
Maybe Go compiling to native binary with excellent performance and being somewhat "simple" (say, compared to Java 8 streams conveniences etc), has given rise to that impression. Though I wasn't under that impression myself (I think Go having a GC compared to usually more manual memory management by systems languages is a pretty significant difference).
hsn915
Substack link if you are reading from mobile or otherwise don't have an adblocker:
B1FF_PSUVM
Drats, not the Norse deity. In case you're also disappointed, I recommend Votan by John James
https://books.google.com/books/about/Votan.html?id=y-OlAwAAQ...
"""
In the second century AD, a Greek nobleman is travelling and living abroad in Germany while carrying on an affair with a military man's wife. When discovered, he takes an emergency business trip to save his life and packs amongst his belongings certain items that lead the people he encounters to think him a Norse God, a fortuitous point of view which he does little to dispel. Forced to keep up the pretence of being a god while staying one step ahead of his lover's jealous husband, Photinus must juggle the severity of his situation with the enjoyment of being a God.
"""
gautamcgoel
Sounds like The Road to El Dorado :)
B1FF_PSUVM
It's that sort of tale, the picaresque adventures of a likeable scoundrel (or two). The John James tale checks most features of the Odin story with explainable real-world incidents.
He wrote a couple of sequels that go on to Irish mythos, etc.
eterps
Nice, it also supports distinct types (Similar to Nim): https://odin-lang.org/docs/overview/#distinct-type
cshenton
Odin is probably the most productive I’ve been in a language. I went from reading the docs to having a working interactive PBD particle sim in VR via OpenXR in around 48 hours wall clock time.
I am currently writing a rigid body engine in it. It is perfect for graphics/games programming.
stephc_int13
The most important aspect of a system programming language, besides performance, is the readability of the code.
It will always be more difficult to read (and understand) a program than to write it, so, unless this is some throw away code, ease of reading should be the priority.
Unfortunately, the speed/ease of writing is often used instead.
Ease of reading means linear, boring, plain English with minimal use of arcane symbols or regex-like expressions.
In this regard, meta-programming is very often counter-productive, as it can introduce new idioms and constructs in the language that have to be understood before reading the program itself.
Overuse of C macros or C++ templates comes to mind, but I think that lack of readability was also a huge problem for LISP and Forth.
debug-desperado
"I like Odin" - me too, just discovered Odin last week. The syntax is just about as perfect as a procedural language can get.
I don't do C professionally and really only used for standard uni classes for algos, data structures, system programming, OS, etc. But seeing Bill's streams highlighting the clarity of the Pascal pointer syntax has been eye opening. A C spiral seems so utterly unnecessary compared to how simple it is to read Odin left-to-right. It's good to have a physicist take on a programming language. Thanks for the hard work!
Get the top HN stories in your inbox every day.
I have high hopes for Odin. There has been a recent trend of C/C++ replacement languages like Zig,Rust,V, etc. with each one trying to find its niche and triumph over its competitors.
Odin's niche is the kind of high performance programming that's done in games and other real time visualization applications.
Other than fixing C's known issues, like having proper tagged unions, fixing macros, and the crazy compilation model among others, it has a bunch of features, that make it appeal to game programmers.
Features, such a structure of arrays support for data oriented design, builtin support for matrices, vectors, and shader-like syntax for 3D math, allocators and the like.
And it certainly doesn't hurt that unlike many of these upstart languages, Odin has a real, successful, commercial product built in it, EmberGen, which is used for CG smoke and flame simulations:
https://jangafx.com/software/embergen/