While Typescript has the gaping hole that is typing external data. Your code can't enforce that in TS, but in Go you're forced to.
I do admit Go has an easily found foot gun: nil pointers. It's a small one though, in comparison to the original problems with nil pointers. More stubbing your toe than shooting your foot.
> This is NOT because I hate Rust. While not my favourite language it's definitively one of the best new ones and I encourage people to use it for new projects where it fits. I do not want it anywhere near a huge C code base that I need to maintain.
Seems pretty clear cut to me.
Why do rust developers demand everything be re-written in their language? Especially one of the longest running, largest and most successful C projects of all time? It was never going to work out.
There are a few brand new operating systems being developed in rust, why not contribute to them instead?
> Why do rust developers demand everything be re-written in their language?
I'm pretty sure Torvalds is the one who decided to add Rust to the Linux kernel.
> I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different. So there's been some pushback on Rust.
- Linus Torvalds
https://www.zdnet.com/article/linus-torvalds-talks-ai-rust-a...
> If you use ctx.Value in my (non-existent) company, you’re fired
This is such a bad take.
ctx.Value is incredibly useful for passing around context of api calls. We use it a lot, especially for logging such context values as locales, ids, client info, etc. We then use these context values when calling other services as headers so they gain the context around the original call too. Loggers in all services pluck out values from the context automatically when a log entry is created. It's a fantastic system and serves us well. e.g.
`ctx.Value` is an `any -> any` kv store that does not come with any documentation, type checking for which key and value should be available. It's quick and dirty, but in a large code base, it can be quite tricky to check if you are passing too many values down the chain, or too little, and handle the failure cases.
What if you just use a custom struct with all the fields you may need to be defined inside? Then at least all the field types are properly defined and documented. You can also use multiple custom "context" structs in different call paths, or even compose them if there are overlapping fields.
Because you should wrapp that in a type safe function. You should not use the context.GetValue() directly but use your own function, the context is just a transport mechanism.
> `ctx.Value` is an `any -> any` kv store that does not come with any documentation, type checking for which key and value should be available
The docs https://pkg.go.dev/context#Context suggest a way to make it type-safe (use an unexported key type and provide getter/setter). Seems fine to me.
> What if you just use a custom struct with all the fields you may need to be defined inside?
> `ctx.Value` is an `any -> any` kv store that does not come with any documentation, type checking for which key and value should be available.
On a similar note, this is also why I highly dislike struct tags. They're string magic that should be used sparingly, yet we've integrated them into data parsing, validation, type definitions and who knows what else just to avoid a bit of verbosity.
Most popular languages support annotations of one type or another, they let you do all that in a type safe way. It's Go that's decided to be different for difference sake, and produced a complete mess.
IMO Go is full of stuff like this where they do something different than most similar languages for questionable gains. `iota` instead of enums, implicit interfaces, full strings in imports (not talking about URLS here but them having string literal syntax), capitalization as visibility control come to mind immediately, and I'm sure there are others I'm forgetting. Not all of these are actively harmful, but for a language that touts "simplicity" as one of its core values, I've always found it odd how many different wheels Go felt the need to reinvent without any obvious benefit over the existing ones.
the second i tried writing go to solve a non-trivial problem the whole language collapsed in on itself. footguns upon footguns hand-waved away with "it's the go way!". i just don't understand. the "the go way" feels more like a mantra that discourages critical thinking about programming language design.
It did not have to be this way, this is a shortcoming of Go itself. Generic interfaces makes things a bit better, but Go designers chose that dumb typing at first place. The std lib is full of interface {} use iteself.
context itself is an after thought, because people were building thread unsafe leaky code on top of http request with no good way to easily scope variables that would scale concurrently.
I remember the web session lib for instance back then, a hack.
ctx.Value is made for each go routine scoped data, that's the whole point.
If it is an antipattern well, it is an antipattern designed by go designers themselves.
People who have takes like this have likely never zoomed out enough to understand how their software delivery ultimately affects the business. And if you haven't stopped to think about that you might have a bad time when it's your business.
Someone has to question the status quo. If we just did the same things there would be a lot less progress. The author took the time to articulate their argument, and publish it. I appreciate their effort even if I may not agree with their argument.
The author gave a pretty good reasoning why is it a bad idea, in the same section. However, for the demonstration purposes I think the they should have included their vision on how the request scoped data should be passed.
As I understand they propose to pass the data explicitly, like a struct with fields for all possible request-scoped data.
I personally don't like context for value passing either, as it is easy to abuse in a way that it becomes part of the API: the callee is expecting something from the caller but there is no static check that makes sure it happens. Something like passing an argument in a dictionary instead of using parameters.
However, for "optional" data whose presence is not required for the behavior of the call, it should be fine. That sort of discipline has to be enforced on the human level, unfortunately.
If you use a type like `map[string]any` then yes, it's going to be the same as Context. However, you can make a struct with fields of exactly the types you want.
It won't propagate to the third-party libraries, yes. But then again, why don't they just provide an explicit way of passing values instead of hiding them in the context?
> why don't they just provide an explicit way of passing values instead of hiding them in the context?
Hiding them in a context is the explicit way of passing values through oblivious third-party libraries.
In some future version of Go, it would be nice to just have dynamic scoping. But this works now, and it’s a good pattern. The only real issue is the function-colouring one, and that’s solvable by simply requiring that every exported function take a context.
Precisely because you need to be able to pass it through third party libraries and into callbacks on the other side where you need to recover the values.
Yeah most people talking here are unlikely to have worked on large scale Go apps.
Managing a god-level context struct with all the fields that ever could be relevant and explaining what they mean in position independent ways for documentation is just not scalable at all.
Import cycles mean you’re forced into this if you want to share between all your packages, and it gets really hairy.
We effectively use this approach in most of our go services. Other than logging purposes, we sometimes use it to pass stuff that is not critical but highly useful to have, like some request and response bodies from HTTP calls, tenant information and similar info.
I'm not particularly impressed by Odin but maybe i'm not the audience. If you like strictly procedural languages (or a die hard C fan) it's probably fine but it feels like a 'My First Language™' kind of project.
What I really miss are methods on structs a'la Go. Just simple receivers would be a great addition imho. Because of this choice, it's affected the entire stdlib and boy does it look old. Creating a typed variable to pass it to a stdlib init function (for allocation, etc) is terrible decision and it's everywhere. The stdlib looks muddled too.
Odin is obviously heavily inspired by Go (among others) but it's learned nothing of the lessons of the Go authors. For example, Odin is a larger language and has fewer features.
I got an ICE while compiling once and it reported something like `TODO(bill) support this`. Not a good look.
i think you probably just aren't the audience. most of the things you miss are things i either am neutral on or actually enjoy (having written about ~20K lines of odin).
the creating a variable and passing to the `init` procedure is something i actually like since it allows me to decouple my allocations and initializations in most cases (barring things that are backed by dynamic arrays like `core:container/queue`). it also ensures that the memory allocated by `init` procedures can outlive the structure that it was tied to, which is especially useful in the case of something like the string builder.
if you simply want "method-style" autocomplete (i'm neutral on that), ols also does support that with `fake_method_completion` where you type `<variable>.<whatever>` and all procedures that take a `T` or `^T` as the first parameter show up as options.
as far as having fewer features, i think it just depends on which ones you're talking about. imo, the odin generic system is much nicer to work with and the presence of real enums, bit_sets, enumerated arrays, `or_return` + friends, and a proper scoped-based defer (instead of go's function based) make it really nice to program in compared to go for me. that being said, the `core:thread` `Thread_Pool` is not a complete replacement for goroutines and i will say that the concurrency model of go works really well for a garbage-collected language. of course, the garbage-collected part there shows why something like goroutines don't really fit well in odin.
on internal compiler errors, unfortunately, in a pre-1.0 language, those are bound to happen. fortunately, the time to fix can often be measured in a matter of hours rather than days/weeks.
Regarding internal compiler errors, I still hit on in MSVC every other month, and that's a compiler that has been in production for many decades at this point.
But as I said to him, did he file an issue and when was this? Because it was probably fixed by now, and if not, we'll try to fix it straightaway.
Odin appears to only recently have been pressing the claim of Go alternative, as a new direction in its marketing hype. There are Go and Pascal influences, but Odin is arguably much more similar to and an alternative of Jai[1][2] (from Jon Blow). Maybe the strategy is to try to distance itself from the label of Jai-clone or Jai-lite.
If Jai goes public beta or releases books (upcoming from Ivo Balbaert), then Jai has the potential to kill off Odin, which appears to only been able to keep a smallish following (relatively fewer GitHub stars and lack of Wikipedia page) since its birth in 2015 or 2016. Odin's popularity, seems dependent on Jai not being public yet.
The languages which are truly close to Go, are: Go+ (goplus)[3], V (vlang)[4], and Borgo[5]. V has the methods on structs, as you have mentioned. Go+ and Borgo compile to Go. V compiles to C, along with other backend options, and has a Go2V transpiler. These languages are more of an evolution of Go, that provide additional features and functionality, and where the influence is much more obvious.
Odin isn't trying to be "impressive", it's trying to be productive as an alternative for C on modern systems.
Odin isn't my "First Language" and closer to my 20th.
Odin is just not for you. Your complaint about the lack of methods means you don't want a C alternative, and that is absolutely fine. I have nothing inherently against methods but I believe that if you are to add them, you cannot just have _mere methods_ but also have something to take advantage of them. But by the time you need such a feature (like typeclasses/traits), it becomes far from being a C alternative now and being something closer in the realm of Rust.
And what about the core library is muddled?
What lessons from Go did I not learn?—I'll take "fewer features" as a compliment too.
> I got an ICE while compiling once and it reported something like `TODO(bill) support this`. Not a good look.
Did you make an issue for this? And how long ago was this? Because this most likely fixed/implement now, and was probably fixed very quickly too.
The 'end of the world' scenario isn't perhaps something that we expect. We always think the end of the world will be disease or natural cataclysm. Also, humanities curiosity can't help itself.
* Imagine AI giving a terrorist network a recipe for the most toxic nerve gas ever discovered. (This has already happened to AI researches)
* Imagine AI being used for deepfake propaganda inciting a war between superpowers. (This is arguably already in progress)
* or it could be the usual sci-fi classic of an AI intelligence becomes superior to humans and just takes over (using the above methods and more).
AI has the ability to be completely undetectable and incredibly insidious. We could be destroyed by a force we don't even notice.
