On Monday, 29 June 2020 at 11:02:47 UTC, Robert Schadek wrote:
> On Monday, 29 June 2020 at 09:09:14 UTC, Cym13 wrote:
>> The original "Phobos is cool" thread encouraged me to share my experience.
>
> Happy to read this.
>
> I love phobos, and think it should grow and include more stuff.
>
> What libs are you missing?

It's hard to pin point. As I explained I don't know from one week to the other whether I'll be working on an AS/400, a new connected lock, some bank's website in Java or a company network with 250k+ different machines.

I don't need 10 XML libraries, but I need 10 libraries parsing 10 different formats. As much as possible. Formats and protocols are the most important for me since it's the first step to be able to talk to the equipment. Anything goes really.

The last I used Python was to parse a huge amount of raw Windows logs. The format isn't complex, I could have written a parser in D, but it was already there in Python so I used that. No regret, I like Python, but it made the choice that easy.

Dear reader, if you happen to work with a strange format that you think nobody has any use of but have a working parser then please upload it somewhere. I'm pretty sure it'll come in handy someday.

On Monday, 29 June 2020 at 12:47:00 UTC, Mathias LANG wrote:
> I'm curious, given your use case, how did you feel about @safe by default ?

As explained in another post (twice actually, my mistake), I can't be against it as a security professional because code safety has real security consequences. But it would make my life harder. How much depends on how it would be implemented.

> If I understand correctly, you're using Linux + DMD ? Have you tried LDC ? It should make those use cases much easier (past the initial getting used to it, but you can just `alias dmd = ldmd2`).

I used dmd, ldc and gdc in that order of frequency, on Linux and sometimes Windows. I prefer cross-compiling though, I don't like the windows workflow but I think it says more about me than D.

> Have you tried https://github.com/jacob-carlborg/dstep ? Did you encounter any issue ?

I've never had a case where dstep proved useful to me. I generally have too much tweaking to make afterward. I stopped trying, I either write a few signatures manually or use dpp (thanks Atila btw).

> Out of curiosity, if you have used Go extensively, was the solution they came up with (Github URL) good enough for you use case ?

I have used Go just enough to know that it's not for me. The github url system introduced more security issues than its worth IMHO, but I say that from an external point of view so I won't comment any further on the topic.

On Monday, 29 June 2020 at 09:09:14 UTC, Cym13 wrote:
>
> But first of all, why should you care?

This is a refreshing read that could believe coming right from the D blog. Not only that, it also is a piece of information how the language really works out in practice.

>
> You probably shouldn't. I'm not a software developer, my company's business doesn't rely on D in any way, I'll never write a killer app or case study and even if I were to share a library it probably wouldn't be maintained more than a week. I'm not someone that'll bring much value back in the language.

I do remember that you have many times helped people at the Learn forum. That already counts as bringing value.

>
> I'm a security consultant. My job is to find security issues and exploit them. I'm sure most of you know about pentesters yet my job goes a bit beyond common penetration testing. I review websites and networks but also attack electronic devices, perform malware analysis, source code review, cryptographic review, human manipulation, lockpicking... Anything goes.

Cool! If you someday want to write about code security to the D blog, I'd likely read it many times over.

> The difference with D is that I can start very scripty, using no explicit type, then adding details in once I have a strong skeleton. I know that style is often dismissed by more industrial users but it's one of the core reasons why I use D.

Huh? I thought that your way is exactly the recommended practice. You're essentially doing prototyping before coding the final product, only in much smaller scale.

> But I can't very well blame anyone not to make malware development easier and none of the issues I had should impact normal development.

I do consider it a plus for a programming language if it's easy to write malware in it. Not only it helps whitehats like you, it also teaches regular programmers to think like hackers and thus secure their code better.

>
> I'm just a selfish user minding his own business.

So are we everyone from some perspective. Even if one contributes to open-source, there's got to be something one skimps on. Do we donate money to good causes? Do we keep our common-interest skills up (first aid, swimming, disaster survival etc)? Do we do any voluntary job for our hometowns? Do we look after our neighbours? For all of thing like these, there are some who can answer yes, but no-one contributes for the common good in every area of life.

>
> Then there's the omnipresent negativity of a huge chunk of the community...  it's rough. I used to read the forums daily until I noticed that it stressed me a lot, made me feel angry and sad and that it wasn't the place I wanted to be. Now I mostly keep an eye on Announce.

Understandable. If one is feeling angry, staying out is the the correct thing. That way it does not add up to the negativity.

>
> I hope it stays that way even though I understand why most trends I see on the forum target more "industrial" users (by which I mean working on month or year-long software development projects in a professionnal setting). I have no expectations from that post, but I wonder how many others use D everyday at work in a similar fashion.

Your way of use is IMO just as important as the large-scale way. D is officially trying to be a scripting language among it's other merits, which means that you're using it just as it's meant to be.

And you are not alone. While I do long-term projects, there is use for scripting every now and then. I transitioned from Windows to Linux an year ago, but I still have not learned to do anything complex with Unix scripts. So when there's mass file handling to be done, I'm likely to roll a D script. Also I did succesfully use the D compiler as a simulator for a school assignment that wasn't even intended for programmers.

> I've tried hard to find a better language than D for my work
Didn't want to derail the forum discussion, thus an off-list message:

What's your take on nim then? Some stuff regarding your post:

- python-esque syntax with d-like performance, lower mem footprint
- also solid type inference story
- semi-realtime gc (and more); all around better than d's gc options
- UFCS
- similar compile-time execution capabilities, hygienic macros
- inline asm statements
- directly include c and cpp headers via pragmas, since nim compiles to c or cpp
- large stdlib; more data structures, parseutils, etc.
  (although nothing as fleshed out as std.algorithm)
- safer defaults, inspired by ada; static verification in the works
- community of similar size and as many third-party libs, it seems

Currently looking at both d and nim myself.

On Mon, Jun 29, 2020 at 07:13:23PM +0000, Dukc via Digitalmars-d wrote:
> On Monday, 29 June 2020 at 09:09:14 UTC, Cym13 wrote:
[...]
> Your way of use is IMO just as important as the large-scale way. D is officially trying to be a scripting language among it's other merits, which means that you're using it just as it's meant to be.

I've found IME that D is very amenable both to scripting-like tasks and larger scale applications.  In fact, it can easily start out as a throwaway script that morphs itself over time into something more permanent.  D has that rare balance between easy enough for scripting tasks, and powerful enough to tackle larger-scale applications -- and providing the expressiveness for a pretty smooth to transition from one to another.


> And you are not alone. While I do long-term projects, there is use for scripting every now and then. I transitioned from Windows to Linux an year ago, but I still have not learned to do anything complex with Unix scripts.  So when there's mass file handling to be done, I'm likely to roll a D script. Also I did succesfully use the D compiler as a simulator for a school assignment that wasn't even intended for programmers.

I consider myself a Linux veteran (I live on the command-line, avoid GUIs like the plague), and I've to say, except for the simplest of scripting tasks, I would not use shell scripts. The syntax is full of inconsistencies and gotchas, and the shell is overly-eager to expand things leading to Leaning Toothpick Syndrome (you have to escape the escape character, often many times).

For anything more complex, D's std.process r0x0rs the boat. I highly recommend it.


T

-- 
One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"

On Monday, 29 June 2020 at 19:28:58 UTC, oddp wrote:
> Didn't want to derail the forum discussion, thus an off-list message:
>
> What's your take on nim then? Some stuff regarding your post:
>
> - python-esque syntax with d-like performance, lower mem footprint
> - also solid type inference story
> - semi-realtime gc (and more); all around better than d's gc options
> - UFCS
> - similar compile-time execution capabilities, hygienic macros
> - inline asm statements
> - directly include c and cpp headers via pragmas, since nim compiles to c or cpp
> - large stdlib; more data structures, parseutils, etc.
>   (although nothing as fleshed out as std.algorithm)
> - safer defaults, inspired by ada; static verification in the works
> - community of similar size and as many third-party libs, it seems
>
> Currently looking at both d and nim myself.

I know of Nim but haven't given it a try for the moment so I'll reserve my judgement. From what I see though, it's basically D with python syntax. I like D, so I'm pretty sure I would like Nim too and it's my backup plan if D takes my toys away someday, but I don't need another D just for the pythony gimmick (for all the love I have of python).

At the moment I just don't see what it brings to the table that could benefit me so I'd rather stick with the more mature language of the two. Yet, as mentionned, it's not a language I have tried thoroughly so take that with a grain of salt.

On 2020-06-29 09:09:14 +0000, Cym13 said:

> For the same reason I am a huge advocate of battery-included stdlib. I know many are of the opinion of moving as much as possible from Phobos into dub.  For me any library that isn't in dub is one more library I have to evaluate, try, keep track of when they update. It's lost time.

That's a very important point.

Most companies I know are using a language with batteries included (even if it's not optimal), to reduce operational hassles. Minimum but powerful libs... External dependencies are the Corona-Virus of software development...

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Monday, 29 June 2020 at 13:03:27 UTC, Cym13 wrote:
> I don't need 10 XML libraries, but I need 10 libraries parsing 10 different formats. As much as possible. Formats and protocols are the most important for me since it's the first step to be able to talk to the equipment. Anything goes really.
>
> The last I used Python was to parse a huge amount of raw Windows logs. The format isn't complex, I could have written a parser in D, but it was already there in Python so I used that. No regret, I like Python, but it made the choice that easy.
>
> Dear reader, if you happen to work with a strange format that you think nobody has any use of but have a working parser then please upload it somewhere. I'm pretty sure it'll come in handy someday.

Maybe https://kaitai.io/ will be useful to you.

On Wednesday, 1 July 2020 at 10:27:21 UTC, kdmult wrote:
>
> Maybe https://kaitai.io/ will be useful to you.

Looks very similar to Google's Protocol Buffers. What is the main benefit of kaitai over protobuf?

On 7/1/20 12:35 PM, JN wrote:
> On Wednesday, 1 July 2020 at 10:27:21 UTC, kdmult wrote:
>>
>> Maybe https://kaitai.io/ will be useful to you.
> 
> Looks very similar to Google's Protocol Buffers. What is the main benefit of kaitai over protobuf?

I was curious too. From their FAQ [1]:

> In short: these projects and Kaitai Struct solve completely different problems.

There follows an explanation that points out how Kaitai Struct is designed to handle existing binary formats like .gif, .wav or .zip.

> So, to summarize:
> 
> * "Have data in memory, need binary protocol" ⇒ use Protobuf & company
> * "Have binary protocol, need data in memory" ⇒ use Kaitai Struct
[1]: http://doc.kaitai.io/faq.html#vs-protobuf