<p>I created my first tutorial on video! It's a regexp primer, for those who are curious, and for those who feel uneasy when seeing a regexp pattern flying towards them. </p>
<p><a href="https://appliedgo.net/regexp">https://appliedgo.net/regexp</a></p>
<p>What do you think? Is it enjoyable or just meh? Is it too long? (I planned for 5-10 minutes and got 18.)</p>
<p>Would love to hear your opinions!</p>
<hr/>**评论：**<br/><br/>1Gijs: <pre><p>I like the subject because I am always struggling with regex. Should use it more maybe to retain the knowledge I have to look up every time again.</p>
<p>However, I do not like to format you have chosen: video. Too much content nowadays is only created as video. Impossible to search through, impossible to skip parts without missing info. Text can be skipped through very fast and still have an idea what parts are about. So its easy to only read those interesting pieces.</p>
<p>Maybe you could add transcript of the text. Even if it is without code. For a 'best of both worlds'.</p></pre>ChristophBerger: <pre><p>Thank you for the feedback. My next video will definitely have a transcript. Also, I plan for shorter videos, so that there is less urge to skip parts of it.</p>
<p>I just need to find a way of turning the mix of keynote slides, slide notes, voice-overs, and (in future videos) screencasts into a suitable transcript without too much effort. </p></pre>Polite_Users_Bot: <pre><p>Thank you for being a polite user on reddit! </p>
<hr/>
<p><em>This bot was created by <a href="http://reddit.com/u/kooldawgstar" rel="nofollow">kooldawgstar</a>, if this bot is an annoyance to your subreddit feel free to ban it. <a href="http://www.github.com/kooldawgstar/PoliteUsersBot" rel="nofollow">Fork me on Github</a> For more information check out <a href="/r/Polite_Users_Bot" rel="nofollow">/r/Polite_Users_Bot</a>!</em></p></pre>PoliteUsersBotBot: <pre><p>Thank you for fully automatically and mindlessly assuming every post with a certain keyword is meant politely! But hey, it's the sentiment that counts.</p>
<p><em>This bot was created by <a href="http://reddit.com/u/spritetm" rel="nofollow">Spritetm</a> For more information check out <a href="/r/Polite_Users_Bot_Bot" rel="nofollow">/r/Polite_Users_Bot_Bot</a>!</em></p></pre>no_strass: <pre><p>Good news, this was one of the last useless message by <a href="/u/Polite_Users_Bot" rel="nofollow">u/Polite_Users_Bot</a> now suspended</p></pre>norbertfuhs: <pre><p>It was enjoyable but to be honest my advice is to avoid RegEx in Go especially on the backend for web apps. </p>
<p>You noted the common problems with RegEx but I would also give Go beginners an link where the idea came from <a href="https://en.wikipedia.org/wiki/Regular_expression#History" rel="nofollow">History</a></p>
<p>So people can figure out the best use case for RegEx is when they just want to have an embedded practical pattern matcher inside their programs.</p>
<p>In my view the only good case to use Regular Expressions is in the frontend because using them to search and replace informations from strings is usally faster then writing own functions in JavaScript.</p></pre>btchsm: <pre><blockquote>
<p>It was enjoyable but to be honest my advice is to avoid RegEx in Go especially on the backend for web apps. </p>
</blockquote>
<p>Why?</p>
<blockquote>
<p>In my view the only good case to use Regular Expressions is in the frontend because using them to search and replace informations from strings is usally faster then writing own functions in JavaScript.</p>
</blockquote>
<p>What...</p></pre>ChristophBerger: <pre><blockquote>
<blockquote>
<p>It was enjoyable but to be honest my advice is to avoid RegEx in Go especially on the backend for web apps.
Why?</p>
</blockquote>
</blockquote>
<p>Backend web apps serve thousands of clients, and much of their code runs in small, fast loops. Performance counts. Regexp matching, on the other hand, is not particularly efficient, compared to specialized string matching algorithms that are optimized for a particular use case.</p>
<p>I mostly write command-line apps where performance does not matter that much, and I find myself using regexps quite often.</p>
<p>In on case, however, I did decide to not using regexps but rather a specialized algorithm (Aho-Corasick in this case). The commandline app I wrote had to filter millions of lines of log files in a short time. </p>
<p>In the same app, I used regexps to parse the command line arguments, and I found I was hittng a wall because the argument syntax had evolved into something too complex for regexps.</p>
<p>It's all about applying good judgement before deciding to use regexp matching.</p></pre>btchsm: <pre><p><em>This might sound rude, which is not the intended tone</em></p>
<p>I don't think you answered my question. You just kinda changed the subject by stating what I'd consider to be truisms.</p>
<ul>
<li><p>"specialized code/algorithms are more efficient than generalized regexps" - if that weren't the case then there would be no need for the specialized code to exist</p></li>
<li><p>"matching a regexp against millions of lines in a short time makes the regexp overhead more visible" - if you're doing that on your backend for every request you're probably opening yourself up for DoS or using the wrong tool for the job or both... but even ignoring that, I still consider it to be a weak argument given my own anecdotal evidence. i.e. for all we know your regexps are <em>written</em> or <em>used</em> poorly or you're measuring/benchmarking far more than just the regexps. Just a few days ago I saw someone give the same advice to avoid regexps and was highly upvoted for it. I couldn't believe what I was seeing when I looked at the sample regexp.</p></li>
<li><p>"regexps are inappropriate when they become too complex for the problem and vice-versa"</p></li>
<li><p>"apply good judgement before deciding to use $tool"</p></li>
</ul>
<p><em>In-case it's not obvious: you don't have to answer, but I will re-state the question more directly below</em></p>
<p>Why should one avoid regexps in Go, especially on the backend of a webapp?</p></pre>hobbified: <pre><p>This entire comment is nonsense and fluff.</p></pre>
