My Two Cents on Marketing

General
1

Interpreting the YouTube Comments

Many comments on this video mention that The Overview is not a good tutorial. Let me say this: I’ve been part of a company where the standard gut reaction to this type of complaint was common. “Well actually The Overview is not meant to be a tutorial and there are plenty of other resources…”

I understand the urge to respond like that. But I can say after seeing it up close it can drive people away in a very damaging way (let me give credit, Bill is very self-aware and I think fairly non-offensive about this). Yes, the complaint is slightly misguided, but be charitable and see through it.

I appreciate a project being modular, including resources. That being said, there is no reason there can’t be a “sane default” of introductory information. A happy path. Perhaps we should find a way to pay Karl to make his book open source, I’m not sure exactly.

Bill, you made a good point about how people think about the layers of a project: langauge, compiler, packages, ecosystem. When people are new they see it all as one thing, that even includes tutorials. I think Odin is actually pretty close to plug-and-play, so why not go an extra step and accommodate bewildered newbies by giving them more instant gratification?

My Concerns

I want Odin to be successful, because I use Odin. I don’t want my projects to fall victim to a decaying ecosystem. Before the video I figured indiscriminate attraction to new users was good.

But now maybe I think attracting the right people for project stability is better. Stability is better than activity as far as I’m concerned. Quality over quantity perhaps.

How to Market?

Odin is C perfected

is one idea.

I have some notion that Odin is analogous to Apple. It gives you access to the same thing as the competitor but in a way that offers a sigh of relief and a serene simplicity.

If you want to lean into this, which is part of “The Joy of Programming” I repeat my earlier suggestion: step into the minds of people who view ‘Odin’ as the whole ecosystem. Commit to making their experience getting started as painless as Python.

Put something on the front page which gives newbies the happy path. I don’t think you need to sacrifice the modularity or generality advanced users want. Look at all the success with people having fun with Odin and Raylib - they don’t all necessarily care about the details behind that, they just finally get to have fun putting pixels on the screen without much obfuscation.

People want to get into systems programming but are intimidated. They don’t want to tell you they don’t understand some of the steps, but they are attracted to Odin because if systems programming is already daunting, the least jank language is a safe bet.

Maybe that’s a good line:

Odin is the least jank systems language

10 Likes
2

I agree @Dad, I think the documentation issue is actually central to everything else - marketing, onboarding, and long-term ecosystem health. Odin is already pratically plug and play. Good documentation enhances discoverability and clarity.

Adding direct links to the Overview page and a new Documentation page is a must. The overview itself should be replaced. Less text and more basic examples. Things like printing, loops, conditionals, file io, and console interaction. That’s the bread and butter for new programmers. Maybe throw in some basic data structures and algorithms. The new Documentation page should be much more comprehensive and easily searchable. Basically the current Overview page on steroids.

Right now, documentation is deeply fragmentated:

  • The current overview page serves as a main reference doc, but key information is scattered - some in the FAQ, some in articles at the bottom of the newsletters

  • Examples are split across demo.odin, the examples repo, and self contained examples in specific packages

  • The showcase is great, but so is awesome-odin which should be referenced somewhere

  • Tons of great youtube videos for people who want to learn that way, including Bill’s streams. It might be worth linking to a few creators. I learned about language features on youtube before they were ever in the official docs. The language is still changing so that’s understandable, but highlights a discoverability problem

Also, I just may be out of the loop on this one but I detest discord. So much critical information locked behind closed doors. You’re not going to find any posts on stack overflow for Odin, and google won’t surface the discord threads where people have run into, and resolved an issue you are dealing with.

And that brings up another thing, the search on the packages page is godawful. If you know what you are looking for, or you just want to browse, it’s great to click through. But if you’re new to Odin and want to learn how to read a file, natually you would type in “read” to the search box. Go ahead and see what that brings up.

Maybe all of this is moot. Part of our jobs is to grok docs/source code and build something. If someone finds Odin, they are already curious and motivated. I just think it could be easier.

I say all of this with love. I want to see this language thrive.

9 Likes
3

I laughed, becuase this is me. :slight_smile: An updated version of my pixels on screen can be found in Showcase section.

My experience so far has been good. I have not found any major fault in the documentation, but as always anything can be made better. Once I embraced the steering towards the source code for documentation, I found it much easier to understand everything. I agree that it is a good idea to do anything that can increase or solidify Odin’s longevity, as I also would not want to see my projects wither. Karl’s book is fantastic. I highly recomend it. It brought me back to the days of my first O’Reilly C++ book when I started in the mid-90’s but without all the extra complexity and syntax that came with OOP.

As for the examples, I found them mostly friction free. Though I would recomend to make sure all examples have a version without special ascii runes, in addition to the special runes that are present. They do add nice flavor considering Odin is a Norse god and runes are from the Norse alphabet (and also same word for tablets - double meaning if I recall), but sometimes they can obscure the point. The most friction I’ve run into so far was with the XML example, which was just the test code for when compiling the library. It would have been better in my humble opinion to instead provide a real-world example of it’s use (i.e. open a file, find and modify an element, copy to a new xml variable, and write to a file). Took me a while to get this, but once I did, I found the XML support was good, just needed a better showcase.

When searching on ddg, I type the phrase “Odin Programming” plus my search, which usually gets me what I want. Even the AI assistant has been mostly helpful, but I will note one thing to concider: I’ve noticed the AI will read from the main documentation the examples of syntax comparisons between Odin and other languages, then use the other languages as the syntax for the answer while still referencing the correct procedures. Maybe find a way to hide those examples from search engines so the AI won’t confuse the syntax.

Edit:
Had one more thought. I recomend leaning on the sugeriest of syntactic features. For example, I’ve come to love using the " ..any" type (maybe too much). Now granted, it could be dangerous, but instead of stating in the documentation “highly recommended that you do not use this unless you know what you are doing”, maybe change this to highlight it’s awesomeness by providing a guide of recomendations to arm the reader with the information they need to “know what they are doing” and use this feature successfully.

Things like:

  • Always check that “any != nil” before using the variable(s) in the procedure, since syntax ols may not warn you that no “any” parameter(s) were provided when calling the procedure.
  • If you want data to live past the clearing of the procedure’s stack frame, pass a pointer “..^any” and save your data with it.
  • Be carefull when overloading with another procedure that has the same parameters but without the “..any”. Using the overload will be ambiguous to the compiler.
  • Either check for type, or if expecting all the same type recomend using a specific type like “..f32” or “..^f32” instead.
  • etc…
5 Likes
4

I will second all of this, I work in the video/web world and in there Go is king because the tooling, documentation and the “it just works” factor are huge pluses. Odin is not far behind, but it is not that approachable to someone who is not willing to put the time into it.

More approachable docs, how X in Y language is done in Odin type of thing would be huge or any kind of cheat sheet (https://cheats.rs/ was incredible useful for me), and more libraries that make the zero to mvp type of development easier.

My company evaluated Odin for some video work, and did not go forth with it due to some of the concerns I mentioned above, plus lack of tooling around other areas (at the time it was interop with C, lack of standard HTTP, SQL drivers, etc).

I know the community likes to keep the language small and focused, and that is the biggest reason I also love it. However, coming from the professional world, most people don’t want or care to put the time an enthusiast would to get the project up and going, they just want to get the thing done. Without any of that, can’t see many companies adopting early, which means the language won’t really leave the “niche” category?

Just some thoughts, from someone who enjoys it personally and failed to bring it to their workplace.

5 Likes
5

Ooh! I personally agree with everyone’s ideas about improving the Docs/Tutorial support. Personally, the docs work fine for me as a single page because I can Ctrl-F, but that’s not as obvious to newer users, and I think an alternate presentation method might be nice to have. Also, your cheetsheet for rust reminded me a lot of how I used cheatsheets when switching from GameMaker to Godot, I feel like a basic “here’s the key things that change from C to Odin” article might be very helpful.

3 Likes
6

There are no examples in the Overview of how to handle input from the keyboard. There is no example in the Demo of how to read a string from stdin. This is a basic feature of most languages, and is normally tutorial #2 right after “Hello world!”

I don’t want to search through dozens of obscurely named libraries with no documentation to try to find out how to read from stdin. I don’t want to have to become an expert on how different operating systems buffer keyboard input. I don’t want to have to write my own console editor just to read a line of text. I just want to write response := readLn(stdin, "Enter your name: ") and have it work. I’m not afraid to import a library to do that, but which one?

Don’t answer me with, “Odin is not a memory managed language.” As a newbie, I don’t care. I just want to read a string from the keyboard. After all, the OS has already put the input stream into a buffer somewhere. I just want to read from the thing. Show me how to flush the buffer after reading from it, and teach me why that’s important.

Advanced features are a draw for experienced users. Don’t make me, the newbie to your language, jump through hoops without a guide for basic functionality. I’ll just go and use Pascal instead.

2 Likes
7

It is in the examples directory: examples/console/read_console_input/read_console_input.odin at master · odin-lang/examples · GitHub

Since everyone is giving their 2 cents, I guess I will too. For most people, Go does everything they need and is easier to use because of garbage collection, goroutines, ecosystem, package manager. You’d only seek out a language like Odin, which takes more effort, if your software actually needs full control, which most software doesn’t.

Being used by few people doesn’t mean it can’t be influential though, C++ powers so much even if most people only use it through Python. Maybe Odin can play a similar role.

2 Likes
8

I for one really like the way the overview is presented. I read the whole thing in one go while on a plane, and felt like I had a good (as the name suggests) overview of the base language, and started writing code. Sure, I still had to reference things and ask questions (I still do from time to time!), but having everything in a single searchable file was very nice.

My biggest issue is that this is not the case for other parts of the docs. I wish the generated docs for say, the linear algebra module had a bit more of an “ordering” to them, something you could read/skim through to get an overview of the entire thing. Heck, even the table of contents for the standard library would benefit from some sort of (non-alphabetical) “ordering” and some paragraphs of text grouping packages/explaining what they’re there for in short.

4 Likes
9

I want to make a few comments if that’s okay:

The Overview is just that: an overview. It was never meant to be a tutorial in the first place, and I am aware of how people interpret it. Tutorials usually want to be a lot more focused, than that. I wrote most of it originally as a form of pseudo-manual rather than tutorial. I tried tutorials in the past but you cannot do that for the entire language, unless you write an entire book (which I highly recommend Karl’s odinbook.com).

demo.odin was the original resource, and I think that now needs to be just added directly to the website. It’s actually a pretty good resource as it was meant to be a pseudo-tutorial-through-code rather than a pseudo-manual like the Overview is.

As for the comments on documentation being the way to market, I think this is putting the cart before the horse. When marketing something, you don’t go “we have good docs”, you market something else entirely. Docs are what keep people there, not what attracts them to the thing. And Odin is no different here.

So people saying Docs are the way to market is objectively wrong and have not understood the question I posed.

The other aspect which I’ve brought up a few times before is when people ask for “documentation”, they usually mean copy-and-pasteable examples, not well written documentation. And over the years, when people do ask for documentation that doesn’t exist yet, they are usually not asking for it for themselves but rather what they think others want (which is pretty much always wrong). We don’t want to waste time on things people don’t actually want/need. We need to know what to allocate our resources (i.e. time) to so that everyone is happy.

A good analogy regarding this would be Direct3D vs OpenGL. Direct3D is an extremely well designed and well documented graphics API but not that commonly used amongst hobbyists compared to OpenGL. One of the main reasons is because OpenGL has loads of copy-and-pasteable examples on the internet, even if there are virtually no good docs on OpenGL out there, not to mention how bad OpenGL is as an API.

3 Likes
10

Zig has gained mind-share through marketing by throwing money at the problem. Zig has its own YouTube channel and a guy doing dozens of videos, plus all the volunteer videos out there. Zig has a conference. Zig has a mascot and I think a plushie. Andrew does lots of interviews.

That doesn’t really seem to be an option for Odin, as there is apparently no real revenue source. Conferences cost a LOT of money, and are really for people you’ve already reached. (Doing a introductory talk at GOTO might be worth it, though.) YouTube gets results, but you have to be consistent and interesting. The 10, 20 and 45 minute formats seem to work. Very few people actually sit down to watch a 3 hour coding live session, and those who do are probably already true believers. I first got interested in Python from watching the short tutorials by Socratica. They’re pretty much the gold standard - but they have money.

A regular (at least weekly) blog that explains and showcases the language wouldn’t hurt.

But what you’ve really got to do is figure out what you’re selling, and then back it without being wishy-washy. You don’t sell a product by telling people to check out everything else first. And then you need a tag line to repeat ad nauseum.

Odin is the sweet spot between C and Go. Odin is the language that marries performance with simplicity and readability. Odin is the systems language of the future, today. Odin is the language C wishes it were. Odin is a faster Go. Odin is the language of bare-metal game programming.

11

OpenGL is the easiest api to make your program cross platform (or used to be), so it’s also the most commonly taught api to introduce someone to graphics programming. The assumption used to be, “If you need to make a hobby project, you don’t need anything more than OpenGL”. That’s the reason. People learned it first through a teacher (either on youtube or through a course) and didn’t need to learn another one for their use cases. You also have to think of what audience is being targeted. Most programmers who specialize in graphics prefer Directx, I’m sure partly because of the better docs.

Also “objectively wrong” is a funny phrase to use when it comes to marketing. Making people aware of Odin, and making people stay with Odin, are the same thing. Who’s going to be making these code examples if people aren’t staying to use the language? Who’s going to make those tutorials online if people try Odin for a bit, can’t get much done, and then move on? Some will remain, like us, but every person who didn’t could have contributed to marketing the language with a richer ecosystem and/or better learning resources. Treating these as separate is a mistake imo.

1 Like
12

The cross-platform aspect is a lie though. It wasn’t even that true 10–15 years ago, you still had to do work to make it work on each platform. If you care only about Windows and Linux, you can probably get away with just OpenGL, but practically you want:

Windows = D3D11 or D3D12
Linux = Vulkan or D3D(11/12) through Proton/Wine
Darwin = Metal
Web = WebGL

n.b. There is WebGPU but that has its own issues too and it’s usually still better to do not use that.

As for my point regarding the marketing of “documentation” be “objectively wrong”, it is though. If you said “Odin is very well documented”, that doesn’t actually attract many people as it still makes you want to ask “okay, but why would I use it?”. So yes they are completely separate things. And no, making people aware of it is not the same as getting them to try it, and thus keep with it. This is my point.

I have to treat them as separate because they are. It’s not a mistake, they’re literally different.

TO BE CLEAR: of course better documentation is a good thing, but it’s not what attracts people to something, and thus not a good thing for marketing.

13

I don’t think that’s entirely fair. Speaking from my own experience, I chose Odin for my recreational programming because it felt powerful without all the fluff getting in the way. The “joy of programming” slogan isn’t wrong. Odin knocked it out of the park in that regard, and the docs/examples are a huge part of what drew me in. I see your point that marketing to new people may require a different strategy than supporting those who discover Odin on their own.

The “batteries-included” pitch is already quite strong. The showcase just needs to be more visible, or maybe highlight some higher-profile accomplishments? We already have a few steam games, and JangaFX is a great example of Odin in use outside of gaming. An easier console pipeline would also go a long way to attract curious game devs. If the hinted-at UI library lands well, building phone and desktop apps will become more accessible too.

Honestly, what you have been doing recently is already putting a brighter spotlight on the language. All of the podcasts and interviews have been great to see, so keep those up if you can. @charles_23195 mentioned conferences as another avenue for marketing and discovery (BSC was fantastic). That said, those are things I personally enjoy, and I already use Odin. Maybe I’m not the best measure of what resonates with newcomers.

I also want to clarify, the docs I mean for marketing Odin to new users isn’t the same thing as more comprehensive documents for existing users.

1 Like
14

no they are not.

making people aware of the language only means you need to show/talk about the surface level stuff. But you need breath of coverage to make find the demographic that would switch to odin.

But having people stay with it and not switch to something else requires good tooling and easily navigable documentation. This needs detailed coverage of the features and standard/vendored library.

15

People can be attracted to Odin and then instantly decide not to pursue it if they think the resources for getting started aren’t good enough. People will hold the resources to a higher standard since Odin claims to be easier to learn and read than similar languages - if that’s true then excellent resources should be easy - is what they’ll think.

Yeah, the demo exists, yeah the overview exists - you could always be correct in saying that whatever anyone needs is in one of those. In reality people probably want something in between. The examples in the demo are good, the explanations in the overview are too.

The demo is a pain to read (it’s literal code after all). It’s good as a reference.

It could in fact be the case that the ‘marketing’ works just fine to attract people to take a look, but they bounce if they don’t like the resources. You’d never really know otherwise unless they tell you that.

Also, if Odin is “easy to learn” then people will expect high quality, free resources. Whether or not they are misguided won’t change that and they won’t stick around for an explanation as to why they’re wrong.

16

What attracts people to a programming language is the feeling that they can do badass stuff with it.

So the best way to market Odin is to help people to build badass stuff with it.

Not telling them that they can do it, but providing paths for them to do it.

Helping them to learn whatever they need to learn in order to do it.

In that sense, I do think that documentation, books, courses, tutorials, videos, examples, etc, have a role in the marketing strategy, but that’s only part of the story. I mean, great docs help you build stuff for sure, but a great standard library helps you even more, same for batteries included, good tooling, and I believe also a healthy community – things like this forum, where we can get help when building our badass stuffz.

Useless to worry about slogans, stunts, whatnot.
Help people to be badass, and more will come.

3 Likes
18

I feel like this talk from cppcon 2014 gives a glimpse of “why Odin?”

I think Odin is a tool for people who care about programming well, and not just duct-tape hacking something together in the fastest/cheapest way possible.

I see the relatively young C programmers who are bothered by cumbersomeness of C, as well as anyone fed up with C++/Rust abstract fantasy world as potential candidates to give Odin a try.

1 Like
19

Perhaps demo.odin could be turned into Rustlings / Ziglings style course.

2 Likes
20

I share the same sentiment as most people here, as someone who recently (a few months ago) picked up Odin.

It truly is a joy to write, and I wish more people gave it a go (hah!)

With that being said, the new user experience is pretty bad. I find the overview itself quite good, but examples repo and demo.odin are not particularly friendly, not to mention very unattractive. If we are talking about marketing the language, that is a very important point as well.

There is no real “book” or “guide” I could point someone interested in Odin to, to start learning the language. At best I could say “read the overview, and look things up in the examples repo and demo.odin and have at it.”

People (myself included) like having a linear, guided experience. The current onboarding is anything but that. The resources are super scattered, hard or impossible to search, and usually contain little to no explanations.

From a purely informational and content point of view, they’re fine. Now that I know most things about the language and have experience using it, I can navigate the demo and examples repo just fine. However, for a new user looking to try Odin, that is such an astronomical turn off, on top of all the usual knee-jerk reaction ones like manual memory management.

I know that compiling all that into a good guide is a herculean task. I know that this is no small thing that can be done over a weekend. But the initial onboarding hurdle is what’s holding Odin back in my opinion.

3 Likes
21

There is Karl Zylinski’s book "Understanding the Odin Programming Language available over on Itch (Understanding the Odin Programming Language by Karl Zylinski). It’s not a a free resource but it’s still very good and Bill has the tweet announcing its release pinned over on Twitter.

1 Like