As someone who for >10 years writes golang and has written some bigger codebases using it, this are my takes on this articles claims:
:Error variable Scope
-> Yes can be confusing at the beginning, but if you have some experience it doesnt really matter. Would it be cool to scope it down?`Sure, but it feels like here is something blown up to an "issue" where i would see other things to alot more important for the go team to revisit. Regarding the error handling in go, some hate it , some love it : i personally like it (yes i really do) so i think its more a preference than a "bad" thing.
:Two types of nil
-> Funny, i never encountered this in > 10 years of go with ALOT of work in pointer juggling, so i wonder in which reality this hits your where it cant be avoided. Tho confusing i admit
:It’s not portable
-> I have no opinion here since i work on unix systems only and i have my compiled binaries specific shrug dont see any issue here either.
:append with no defined ownership
-> I mean... seriously? Your test case, while the results may be unexpected, is a super wierd one. Why you you append a mid field, if you think about what these functions do under the hood your attemp actualyl feels like you WANT to procude strange behaviour and things like that can be done in any language.
:defer is dumb
-> Here i 100% agree - from my pov it leads to massive resource wasting and in certain situations it can also create strange errors, but im not motivated to explain this - ill just say defer, while it seems usefull, from my pov is a bad thing and should not be used.
:The standard library swallows exceptions, so all hope is lost
-> "So all hope is lost" i mean you already left the realm of objectiveness long before tbut this really tops it. I wrote some quite big go applications and i never had a situation where i could not handle an exception simply by adjusting my code in a way that i prevent it from even happening. Again - i feel like someone is just in search of things to complain that could simply be avoided. (also in case someone comes up with a super specific probably once in a million case, well alrways keep in mind that language design doesnt orient on the least occuring thing).
:Sometimes things aren’t UTF-8
-> I wont bother to read another whole article, if its important include an example. I have dealth with different encodings (web crawler) and i could handle all of them.
:Memory use
-> What you describe is one of the design decisions im not absolutly happy with, the memory handling. But than, one of my golang projects is an in memory graph storage/database - which in one of my cases run for ~2years without restart and had about 18GB of dataset stored in it. It has a lot of mutex handling (regarding your earlier complain with exxceptions, never had one) and it btw run as backend of a internet facing service so it wasnt just fed internal data.
--------------------
Finally i wanne say : often things come down to personal preference. I could spend days raging about javascript, java, c++ or some other languages, but whatfor? Pick the language that fits your use case and your liking, dont pick one that doesnt and complain about it.
Also , just to show im not just a big "golang is the best" fanboy, because it isnt - there are things to critizize like the previously mentioned memory handling.
While i still think you just created memory leaks in your app, golang had this idea of "arenas" which would enable the code to manage memory partly himself and therefor developt much more memory efficient applications. This has stalled lately and i REALLY hope the go team will pick it up again and make this a stable thing to use. I probably would update all of my bigger codebases using it.
Also - and thats something thats annoying me ALOT beacuse it made me spend alot of hours - the golang plugin system. I wrote an architecture to orchestrate processing and for certain reasons i wanted to implement the orchestrated "things" as plugins. But the plugin system as it is rn can only be described as the torments of hell. I messed with it for like 3 years till i recently dropped the plugin functionality and added the stuff directly. Plugins are a very powerfull thing and a good plugin system could be a great thing, but in its current state i would recommend noone to touch it.
These are just two points, i could list some more but the point i want to get to is : there are real things you can critizize instead of things that you create yourself or that are language design decision that you just dont like. Im not sure if such articles are the rage of someone who just is bored or its ragebait to make people read it. Either way its not helping anyone.
Other commenters have. I have. Not everyone will. Doesn't make it good.
:append with no defined ownership
I've seen it. Of course one can just "not do that", but wouldn't it be nice if it were syntactically prevented?
:It’s not portable ("just Unix")
I also only work on Unix systems. But if you only work on amd64 Linux, then portability is not a concern. Supporting BSD and Linux is where I encounter this mess.
:All hope is lost
All hope is lost specifically on the idea of not needing to write exception safe code. If panics did always crash the problem, then that'd be fine. But no coding standard can save you from the standard library, so yes, all hope about being able to pretend panic exits the problem, is lost.
You don't need to read my blog posts. Looking forward to reading your, much better, critique.
its based on Three.js and creates great 3D graph visualisations GPU rendered (webgl). This could make it alot more interresting to watch because it could display actual depth (your gpu is gonne run hot but i guess worth it)
I think, while i agree to "problem with LLMs is just with training" i also think to a certain degree we need to step back from LLM's as in text processors and to achieve "AI" as in something really intelligent we need to go more abstract back to NN and build a self learning "entity". While LLM's accomplish fascinating results, we are trying to force speech as the primary way of learning, tho this is a really limiting factor. If we would accomplish to create an NN driven AI in a virtual space which would have an simulated environment and learn from a base state like a "newborn" it still could accomplish the skills to understand language as we humans prefer to use it, tho it wouldn't be limited in "thinking" in and only based on this.
I know this is a very simple and abstract way to explain it but i think you get my point.
Towards the simulated AI learning environment, theres this interview with Jensen Huang that i can recommend in which he touches on the topic and how nvidia is working on such https://www.youtube.com/watch?v=7ARBJQn6QkM
While im not a "expert" in this topic, i might have spend quite a portion of the past 10 years in my freetime to think about it and tinker, and ill stick with the point - we need a free self-trained system to actually call it AI, and while LLM's as GPT's nowadays are powerfull tools, for me those are not "Artificial Intelligence" (intelligence from my pov must include reasoning, understanding of its own action, pro-active acting, self-awareness). And even tho the LLM's we use can "answer" to certain questions as if they would have any of those, its just pre-trained answers and they dont bring any of those (we work on reasoning but lets be fair its not that great yet).
Very nice work :) especially that you even support building sideways and the "hover" always is perfectly placed. Thats something that amazes me the most how clean it feels to place a block. Very good job!
You're going to read the configuration in a target programming language
So if the config format has its own type system you then have to convert between config types and language types
If the config type doesn't map exactly onto the target lang type you either ignore it and accept some values won't round-trip cleanly or without error, or you fall back to using strings (e.g. various possible integer type sizes, signed/unsigned etc, or decimal values via JSON)
Not saying it's always the right choice, but I can see why having lowest common denominator stringly-typed values as the config format can be seen as a feature allowing you to define the type system that the config will be parsed under to suit each particular application
I see your argument tho maybe im just not getting the real use case.
Because when saying defaulting back to string and thatfor ignoring typing, wouldnt that just be the same as beeing typeless? Therefor doesn't every format support string therefor supporting typeless?
Also, in how many cases do you need to parse the same configuration in multiple different languages?
Im not saying its not useful - i just try to get the use case for this arguments.
Here's an actual case I ran into with JSON and it's bizarre number treatment:
Neo4j uses 128 bit ids. The JSON API retrieves these ids as strings of digits, Python library reading this JSON decided to interpret these as double precision floats. And sometimes it works, other times: not so much...
The whole selling point of configuration formats is to allow multiple languages to access the same data. So, cases when multiple languages have to read the same configuration format are exceedingly common.
The fact that the format supports other types means that someone (probably not you) will use those types, and then (probably you) will have to deal with the mess created by that person. I don't trust programmers in general to write good code... if possible to prevent them from writing bad code, then why not?
Well im working alot with json in my job and privat coding life used from all sorts of different languages, and so far i always could sort stuff out.
And well - if anyone trusts external coders he should be damned (or isnt he already for doing so? never trust external data - the golden rule...)
Your case is interesting, i worked with Neo4j years ago in a PHP project and never run into such issues, but maybe i was just lucky.
Nowadays i code mostly golang and im always making sure that whatever an external party sends me is what im expecting (validation ...).
To your point of preventing somebody to write bad code - i've given up on that. Whenever i thought the environment will enforce someone to write proper code, people proof me to be wrong be finding new ways to do the most absurd things.
But ye, its worth a try.
So - why i question such a thing? Because i'm not a fan of adding more and more 3'rd party dependencies to my projects. And while confetti might be a good thing (i never said it can't be) it wont get into any default packaging in a forseeable future meaning i have to make sure that the dependency stays stable which adds another task and liability on my end. So instead of having to deal with the devil i know (validating json data) i have to deal with a new one to eliminate the old one.
Time will tell if confetti will make its way into stable reliable state for common languages - than i might give it a try.
I think parsing the config in multiple target langs is definitely a counter-example where having a type system in the config lang can be useful as a lowest common denominator that you then conform all the parsers too
I guess its because you can allow for custom data formats. You'll have to validate/parse the file anyways, and maybe having utc timestamps is worse than local date-time notation. Especially if the user is supposed to edit the file by hand.
I know for sure I'd like "timeout: 1h6m10s" more than "timeout: 3970". So unless you want to support really specific datatypes just being typeless is better. Putting everything in double quotes to get a string, while spec-wise would be typed, is not enough when the backing data type is not going to be a string. So you might as well throw it away and let the program handle all type conversion.
So i get your point with date/time - while i may be an oldie with still preferring just having an integer seconds - but thats subjective to me.
Tho the quote for string argument i can't fully agree on. While sure in for example a json i would have to quote the values if i want them "typeless as string" - tho json is far supported everywhere and i'm able to interpret the parsed string values in whatever way i want to.
Adding a new dependency (confetti parsing) to spare out quotes doesn't seem to be worth the convenience to me.
I mean im not shocked by neither the fact this happend nor the content. it portraits the staff exactly as i would imagine them.
Tho i still find it kinda amusing that this is the finally proofs that the average security invested joe has a better opsec than the highest ranking us gov officials.
I mean, if theres people that need this i won't judge - but im in tech for ~20 years now and its really not hard to formulate interview questions if you know what the target position is and also have a little of social skills.
:Error variable Scope -> Yes can be confusing at the beginning, but if you have some experience it doesnt really matter. Would it be cool to scope it down?`Sure, but it feels like here is something blown up to an "issue" where i would see other things to alot more important for the go team to revisit. Regarding the error handling in go, some hate it , some love it : i personally like it (yes i really do) so i think its more a preference than a "bad" thing.
:Two types of nil -> Funny, i never encountered this in > 10 years of go with ALOT of work in pointer juggling, so i wonder in which reality this hits your where it cant be avoided. Tho confusing i admit
:It’s not portable -> I have no opinion here since i work on unix systems only and i have my compiled binaries specific shrug dont see any issue here either.
:append with no defined ownership -> I mean... seriously? Your test case, while the results may be unexpected, is a super wierd one. Why you you append a mid field, if you think about what these functions do under the hood your attemp actualyl feels like you WANT to procude strange behaviour and things like that can be done in any language.
:defer is dumb -> Here i 100% agree - from my pov it leads to massive resource wasting and in certain situations it can also create strange errors, but im not motivated to explain this - ill just say defer, while it seems usefull, from my pov is a bad thing and should not be used.
:The standard library swallows exceptions, so all hope is lost -> "So all hope is lost" i mean you already left the realm of objectiveness long before tbut this really tops it. I wrote some quite big go applications and i never had a situation where i could not handle an exception simply by adjusting my code in a way that i prevent it from even happening. Again - i feel like someone is just in search of things to complain that could simply be avoided. (also in case someone comes up with a super specific probably once in a million case, well alrways keep in mind that language design doesnt orient on the least occuring thing).
:Sometimes things aren’t UTF-8 -> I wont bother to read another whole article, if its important include an example. I have dealth with different encodings (web crawler) and i could handle all of them.
:Memory use -> What you describe is one of the design decisions im not absolutly happy with, the memory handling. But than, one of my golang projects is an in memory graph storage/database - which in one of my cases run for ~2years without restart and had about 18GB of dataset stored in it. It has a lot of mutex handling (regarding your earlier complain with exxceptions, never had one) and it btw run as backend of a internet facing service so it wasnt just fed internal data.
--------------------
Finally i wanne say : often things come down to personal preference. I could spend days raging about javascript, java, c++ or some other languages, but whatfor? Pick the language that fits your use case and your liking, dont pick one that doesnt and complain about it.
Also , just to show im not just a big "golang is the best" fanboy, because it isnt - there are things to critizize like the previously mentioned memory handling.
While i still think you just created memory leaks in your app, golang had this idea of "arenas" which would enable the code to manage memory partly himself and therefor developt much more memory efficient applications. This has stalled lately and i REALLY hope the go team will pick it up again and make this a stable thing to use. I probably would update all of my bigger codebases using it.
Also - and thats something thats annoying me ALOT beacuse it made me spend alot of hours - the golang plugin system. I wrote an architecture to orchestrate processing and for certain reasons i wanted to implement the orchestrated "things" as plugins. But the plugin system as it is rn can only be described as the torments of hell. I messed with it for like 3 years till i recently dropped the plugin functionality and added the stuff directly. Plugins are a very powerfull thing and a good plugin system could be a great thing, but in its current state i would recommend noone to touch it.
These are just two points, i could list some more but the point i want to get to is : there are real things you can critizize instead of things that you create yourself or that are language design decision that you just dont like. Im not sure if such articles are the rage of someone who just is bored or its ragebait to make people read it. Either way its not helping anyone.